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

What works out of the box is JSON files with string key-value pairs for source text. For documentation the qqq.json that is "just-another-language" is what we use most often. The strings of that file are parsed as wikitext using MediaWiki syntax and displayed automatically to translators.

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?

Okay, I have been thinking this for a bit. I don't have a perfect solution, but I have the following proposal.

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.

oops, i dont think i meant to submit to this repo

This all seems reasonable, I'm actually not 100% sure what happened so I'll try to gather a better understanding of the situation ;)

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.

Thanks, I'll look into this further. I didn't install it myself, I'll ask sysadmin permissions to get through the setup personally.

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.

I suspect this might be because the value for "Continue" is an empty string here: https://secure.phabricator.com/source/phabricator/browse/master/src/applications/harbormaster/customfield/HarbormasterBuildStepCoreCustomField.php$27 ; At least, changing that value to be non-empty seems to solve this.

Actually, I can reproduce this at HEAD using a HTTP request step.

None of your versions exist here, meaning you have some local changes which might cause this.; Can you reporoduce this on Phacility?

Something else on your server is likely altering URLs. What OS is this? Is this a shared host? Do you have software like apparmor running? All things to look into.

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.

Yup, purging caches didn't help.

Unfortunately, we can't move forward, then.

I'm sorry, other than:

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.

I created a test-event now, it starts in an hour, and I will take a look if this occurs again.

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.

I understand bot users don't get email but I totally mis-typed one and I realized it "too late" and would love to be able to change it even if it doesn't really matter