Hmm, can you try creating a test event on this install to see if you can reproduce it here? I played around with this a little bit locally but wasn't able to get it to break.

We now export strings into projects/<project>/<group>/en.json, etc. For example, here are strings which appear ONLY in Maniphest:

Okay, I believe we already produce a format which is compatible with that definition:

Maybe it would be simplest if you just give me an example of exactly what you want us to emit?

That sounds fine to me. Do you have any preference on what format you'd like the proto-english + variable type annotations in? Maybe something like this, since it sounds like you're doing some level of custom stuff on your side anyway?

Thanks for the report! I think D16924 should fix this, and one other issue that came up too. Both these are related to supporting multiple partitioned masters in connection with T11044.

If this reproduces at HEAD, it's a bug. Please file a new bug report with complete reproduction steps and version information.

I'm sure if I keep digging we'll be out of this hole in no time.

I'm not sure if D16857 is even close to the right level of generality or correct approach and the answer has yet to come to me in a dream, so I'm going to push forward on top of it and see how far I get. If too much stuff stacks up I'll maybe shove this stuff into an experimental branch for now until I decide whether I'm throwing it all away or not.

What do you need on differential.querydiff? We could just give you a modern differential.diff.search with a revisionPHIDs constraint.

sorry please do not fire me

The long-term fix is putting this stuff on EditEngine (some discussion in T11887) but this should be fixable in the short term.

Generally, our behavior here is approximately the same as Calendar.app and Google Calendar. T11804 documents how various edge cases behave in those applications. I believe our behavior is no more spooky in any case I'm aware of.

Unfortunately, we can't move forward, then.

Maybe this is a misinterpretation of "All Future Events"? That means "All events which start after this event starts", not "all events which have not yet occurred, considering the current time".

I'm still having trouble figuring out which past events were edited. Downstream has this query:

Oh, sorry, E66 would have been disconnected from past events by the edit. Let me look through the downstream task.

Assuming that's just a miscommunication, I can't immediately reproduce this locally:

E66 is the first event in the series, so I would expect editing E66 "All Future Events" to edit every event in the series: there are no past instances. Am I misunderstanding? What's an example of a past instance?

I'm not sure, then. You have the B rule, and your Apache is recent enough to support the B flag.

This seems to be working now. I'm going to let it sit in production for a while and see if any issues crop up before considering it resolved, but it seems like everything is working smoothly.

I configured 003 to replicate to 004:

Okay, we're headed back into readonly mode shortly to set up replication. I'm going to verify D16916 along the way so there may be some "partitions disagree about life" errors.

Here's what I've done so far:

I'm partitioning secure.phabricator.com now. Things will drop into read-only mode for a bit.

Okay, what version of Apache are you running? (httpd -v or similar may tell you.)

• T11908 is a followup for executing queries for multiple applications on a single connection. I believe the pathway for that is straightforward and fairly short, but that no install would really reap substantial benefits from it today, so I don't expect to pursue it for some time.
• I believe everything else is now complete, so I'll put this in production as soon as everything here lands and we can see what catches on fire.

No problem, thanks for the report!

I've marked D16909 as fixing this, but it just removes mysql.implementation, and uses the rule "mysqli if available, mysql otherwise".

I think this should be fixed now. Note that we still have T11165 floating around which may make it look like this is still an issue, by sending you to the wrong place when you hit "Save". That bug is dumb but fairly harmless so I haven't chased it down yet.

Oh, hrrrm, this is actually more involved since it's not just the .git clone URI that's in trouble. So I can't just ban . without fixing existing short names.

Okay, let me ban them for now and if it causes too much of an issue we can try just banning .git at the end.

Partly, just haven't gotten there yet.

(This is T6740, not T9979.)

(Is this a performance concern or do you just want like 6 fewer lines of code to maintain?)

Feel free to add it to Community Resources, you should be able to edit that page.

This is because we now recognize shortname.git in some cases, and it's ambiguous if quack.git is "the repository with shortname quack.git", or "the repository with shortname quack, addressed as a Git repository".

WMF has extensions and modifications to Phabricator so you shouldn't report anything you experience on that install to us directly. Report it locally, make sure it isn't because of an extension, then bring it upstream. The versions we could show you would not be useful anyway because they'd be hashes of local commits which do not appear in the upstream, so we would just close your report as invalid and say "test with unforked code before submitting a report" anyway.

I've marked D16905 as resolving this: we now recommend a minimum value (33554432).

See also T10246#163438 for Drydock, and the Harbormaster / Drydock documentation.

Here's the general shape of how to do this. Since we encourage synchronous pre-review lint to fill this role instead of asynchronous build-like processes, support is much rougher than support for lint.

Have you looked at the existing lint support already?

We have at least one tricky issue remaining: when applying storage upgrades, we currently apply them like this: