I think it would be preferable to keep a log of bulk edits that were performed in a global(?) history, and allow them to be reverted easily? I think that would mitigate the issue described in the comment above, and provide value in the event someone unintentionally bulk edits the incorrect set of tasks / objects.

I mean none of these things are show-stoppers in the example above, but you can imagine how bad things would be over a link between the Sydney data centre and N. California if it was happening all the time.

There's probably almost certainly a correlation there that link speed increases with lower latency because of proximity? But having an SSH proxy accidentally pick a link that's say in Oregon instead of North California because at the time of sampling some local network issues were being had that made the local copy appear worse would be a reasonably bad situation for a few reasons:

Gut feeling is that network latency almost certainly isn't the only reasonable concern here.

I don't currently expect anyone to be deploying multi-region clusters in the first iteration of real clustering

(Unrelated note: That side bar design is probably useful for things like Harbormaster build views, especially if we could anchor it to the page as the page scrolls)

Just throwing my input in here:

(Those two things seem reasonably separate, so this might be better split into two issues, but I'll leave it up to @epriestley to decide that; I just wanted to get better visibility on the discussions that happened around those original code reviews in case any community member wanted to tackle implementing these features with upstream guidance)

I managed to find the original restart target feedback that @epriestley wrote.

The goals here don't align with upstream, so I've consolidated the general feedback from @epriestley into T10870.

There were also some comments around embedding build plans (with individual build steps being restartable), but I can't find them now. I'd like to pursue these features in the near future, as we're finding Jenkins "multi-configuration projects" don't actually allow you to restart individual builds (which we rely on because AWS is inherently unreliable in it's operations).

This seems reasonably easy to tackle. Roughly:

Well we could use Maniphest for commenting on documents, except that Maniphest tasks don't have a hierarchy to them.. neither do all of those other applications.

We're not signing off on the textual or structural changes, we're just agreeing that the ideas expressed in the document are what we all understand them to be.

That task seems to be about reviewing structure of the document whereas we want to discuss ideas and content (and we don't need or want a formal review process).

I think a way of addressing the issue is to set the "There are 10 previous comments (show all)." bar that appears in transactions to at least comments that were made after the last change to the document.

Oh I was going to write something up today on this, but this works too.

Stylistic nitpicks

Looks like this was caused because my upgrade didn't upgrade all the way to HEAD (for some unknown reason :S ).

i fixed it

Fix linter weirdness and add comment

• If /w/x/ exists and is titled "History of X", it would be nice if [[ x ]] generated a link with the text "History of X" instead of a link with the text "x". Today, you must do [[ x | History of X ]] to get the proper link text.

@epriestley Passing the slug through to Remarkup like this feels like a bit of a kludge; especially because the preview window requires making a new preview controller. I'm not sure how to proceed with this?

Yeah that was my plan; relative links on non-Phriction pages just won't get marked up.

@epriestley Can I write and submit a patch for this?

Yeah, that's why I think it's probably time to just turn it on by default.

The flag was initially added to minimize the impact of fixing the broken streaming that Windows has by default. Without this flag on, you can't actually stream data from a process's standard output to PHP in realtime; you have to wait for the output to be fully buffered.

what could go wrong

You probably need to configure Apache to correctly route the web sockets.

Yeah that Docker instance is maintained by me. It's not intended to sit behind any kind of load balancing though (unless you're routing WebSockets directly to the client). Otherwise I have no idea if your Apache load balancer is interfering with the connection.

That change already exists in D10555; upstream doesn't want it.

Beyond observing the way the kernel tracks command lines for processes using something like Process Explorer, you can see that this single string vs array of strings is evident even in the way that Windows launches processes as opposed to the way Linux launches processes.

Command Prompt escaping is broken anyway because the Windows kernel only tracks arguments as a single string; it doesn't not separate command-line arguments as an array of strings like UNIX-based kernels. This means that programs like Git that are compiled with msys or mingw will parse their command-line arguments differently to native applications that use the Visual C++ library. On Windows, it's up to the C++ library that invokes main to parse the arguments from the string that the kernel provides, and this is why we have so much difficulty correctly escaping for commands on Windows, because the style of escaping is per-command.

But not everything is running through Powershell? When Arcanist runs (which is using this function), it escapes for the Command Prompt, not Powershell. The Powershell escaping here is for Harbormaster, when commands are explicitly launched by passing them to powershell.exe. It won't have the correct behavior to escape commands for Windows.

This isn't the correct fix, you should call setEscapingMode in the caller instead.

This would make Calendar actually useful for us.

I still use this and continuously rebase it on the latest version of Phabricator, but I don't plan on doing the work to implement "Embed build plan" with artifact expiries or anything like that since it's a significant amount of work and since Harbormaster isn't a focus for upstream right now (based on the feed), it's unlikely any work in this area would be reviewed for quite some time anyway.

This hasn't had any feedback from upstream, so I'm going to abandon it.

As per @epriestley's feedback, this isn't a good way forward.

Abandoning this because I don't have time to maintain it. @epriestley feel free to pick this up again once you're scaling daemons in the Phacility cluster.

Closing this off as I don't use dynamically allocated hosts any more (it's too much maintenance of custom patches).

I'm hesitant to provide further discussion on this issue because of conversation above, but never-the-less in case anyone else using Windows stumbles across this issue, then here's the following advice:

I believe our Harbormaster log table is several GBs in size and by several GB I'm talking 20-80GB range depending on the last time I hard deleted the records.

Upstream generally doesn't review feature diffs from third parties, if at all. You should probably be expecting a response time in the range of "months" to "never" when it comes to diffs.

I don't think it's likely this will be accepted as it creates unnecessary transactions against the buildable just for Herald.

This is a super minor issue and not blocking anyone, so I'm changing it to Wishlist priority to designate how much I don't expect upstream to spend time fixing it.

what did Chrome even do here