As far as I can tell, Amazon RDS allows configuration of sql_mode. Here's their announcement of support (from May 2016):

See also T7787 for plans to support existing !cc stuff from arc on the CLI.

(This doesn't really follow the rules as a feature request because it's just 35 copies of "other systems implement it so you should too", but I think it's something we would probably implement anyway sooner or later so I'm fine with keeping it open.)

Presuming this was resolved by D16967, let me know if there was more to be done.

Try putting MaxStartups 1024 in your /etc/ssh/sshd_config (or similar).

@csilvers, not sure if you got directed here from IRC. See also T11932. At HEAD, we'll now issue more explicit guidance about the required index rebuild.

Hmm, I'm guessing this wasn't clear from the workflow either, then?

Why did you allow everyone everyone edit the event?

Everyone can see from which url a calendar event came.

Please read Contributing Feature Requests carefully before filing a feature request.

That didn't seem to be the case. It might have been because we only enforced Google authentication around one year ago, before that users could use a password for authentication. I can check later today, but perhaps the users that ended up with duplicate accounts never setup Google Auth.

If the only way to register is Google, it should be impossible to create more than one account per Google account.

Why is registration disabled?

To provide some additional context, we originally allowed users to register their own accounts, but we eventually disabled this because we ended up with around 30 duplicate accounts (users with more than one account). I think that this happened because users had listed an alias address in their Phabricator settings, but Google was using a canonical email address to authenticate, which didn't map to any existing user accounts (we have a lot of users that have aliases set up. For example, abraham@mycompany.com would be an alias for the canonical alincoln@mycompany.com address).

This one is fine, I'm still going to fiddle with "in" too.

We haven't received more information about this in a few days, so I'm going to close it. Feel free to file a new request in the future, we just prefer not to keep requests open if they're outside of our control to move forward with.

We haven't ever experienced this, nor have we seen reports of users other than you experiencing it. This ("basically prevent the server from doing any other work") doesn't sound like a description of how properly configured servers are generally expected to work. My expectation of modern systems is that they have sophisticated schedulers which are largely fair in allocating resources and produce generally reasonable behavior, and this is consistent with my experience.

If this feature is valuable for you, I think you should implement it in your mail client rather than pursue implementation in every piece of software you use for work. A client-side solution could give you complete coverage with one implementation, and would be more powerful because it could perform additional filtering (e.g., allow important emails through even during off times, or deliver messages but not play an audio alert during off times, or ironically block family communication during work hours instead).

• Please report security issues via HackerOne.
• This isn't a valid bug report: it is missing required information. See Contributing Bug Reports.
• I can't reproduce this. Here's an HTML file which is properly escaped:

Feel free to file a new task when you encounter actual problems with real text and we can look at adjusting the limit, adding an additional block-level difference phase, rewriting PhutilEditDistanceMatrix in C (see T2312), or other approaches. We can make a better decision based on concrete examples of where the current solution is falling short than by guessing where issues might arise.

Here's the revised dialog after D16956:

I don't think that edit is always invalid: offhand, one reason you might want to make such an edit is so that you can add a tag to all events in a series, allowing you to query them so they can be exported to another calendar. Another case I could imagine is wanting to correct a mistake in the description of an event when you know nothing will be lost by editing future events (e.g., because you are the only user who can edit the event).

No.

(To answer your question more directly: yeah, no way to do pht() with variables in Javascript. We can build that without TOO much trouble, but I'd like to wait for a really good use case first.)

I do not plan to pursue any variation on points which can not be summed in a linear way. You can find some discussion under "Quantitative" in T4427#157820.

I'd say just get rid of it, or render "X / Y" without pht()?

• Availability cache build on All-Day events may be off, I didn't pick up a dot for E1222.

The panel was updated in D16806, on Nov 6. Upgrade Phabricator to see these changes.

Couple of other things:

Likewise if this only might cause confusion, but has not actually caused confusion yet, it's a hypothetical problem (see Hypotheticals). We don't accept requests to address hypothetical problems because they often never actually occur.

This request doesn't describe a root problem (see Describing Root Problems), but we can only accept feature requests which completely describe root problems. See Contributing Feature Requests for more.

That setup is not supported, and we already raise a setup warning making it clear that major features will not work until the base URI is configured.

Why did you choose to ignore the warning, considering that it says "major features will not work properly" until you configure it?

When phabriator.base-uri is not configured, you should receive this setup warning:

@20after4, just a heads up:

As far as I understand, E66 acts as a prototyp (or template), providing defaults for when the individual instances are "materialized" later, when they are edited. Is that correct?

E1218 seems to have worked properly after the patch, at least.

I'm pretty sure D16937 fixes this, thanks for the report! Let us know if you're still seeing issues after that.

I think this should be fixed in HEAD now, but you may want to wait a few days to update (e.g., until stable promotes on Friday) since a few bugs related to T11044 have been cropping up since it landed a couple days ago.

Yeah, looks like that reproduced it. Here are the caches:

After D16933, the behavior of arc browse <branch> on the experimental branch is:

Sorry, can't make it this time! I'll catch you guys next time for sure.

Sure, not a problem.