D19762 adds a "supplemental allocation" behavior, which basically lets blueprints say "I want to grow the pool instead of allowing this otherwise valid lease acquisition".

After that, both hosts will have resources and jobs will allocate randomly, which should be good enough.

I believe you can work around this today by disabling the binding to host "A" in Almanac, running one job (which will be forced to allocate on host "B"), then re-enabling the binding. After that, both hosts will have resources and jobs will allocate randomly, which should be good enough. This is exceptionally cumbersome and ridiculous, of course (and it's possible that it doesn't even work).

Well, this sucks... But thank you for taking the time to explain the situation 😃

It's "open" in the sense of Apache-licensed and (mostly) developed in public (e.g., the information on this install is public rather than hidden behind a corporate veil).

@epriestley Does this mean that phabricator isn't open to contributions?

See Planning.

@epriestley
Support for PHPUnit 5.x ended on February 2, 2018.
We need this patch for PHPUnit 6/7 ... any idea when it can be landed on master?

This was almost certainly resolved by D16273.

Changes in T13209 make this the only mode.

This is effectively fixed by T13098, which modularizes test output.

This doesn't have a repro and will probably be fixed via rewrite / modernization in T13077 anyway.

See PHI801. This is a similar case to the one above, but I think the underlying use case was a bit more compelling: the install was transitioning from a set of older web nodes to newer web nodes as a part of a general infrastructure upgrade, and making various fixes to the deployment and support software as part of that process. One aspect of these adjacent fixes was changing the path from /something/something/phabricator to /something-else/something-else/phabricator (I think as a consequence of adjusting deploy strategy), so newer nodes would have a different absolute path than older nodes. Both sets of nodes were in production simultaneously.

The workaround does not work for me on Debian 9.5 with OpenSSH 7.4p1. Actually I am surprised this worked for anyone, since the issue appears to be that the buffer of the pipe between ssh-auth's stdout and the parent's stdin is being filled, hence ssh-auth blocking at some point. It should not matter how fast these buffers are being filled...

We have a more reliable break for this now, in the form:

I can't get anything to break at all now. 💁

I made a change like this to split responses into small blocks and give each a random chance of failing (I tried 4096 and 4027, a prime near 4KB, as miniblock sizes):

A recent, probably more concrete issue that I've seen is that wget of a large file can succeed (wget automatically resumes) but we can end up with a file that has different content than the original, which is disastrously bad.

Confirmed on PHPUnit 7.2.2 👍

This problem fixed by T13140. Thank you.

Since there's no known actual problem with this today, I don't plan to fix it.

I don't currently plan to change the remaining edge case behaviors since I'm not sure they ever occur in the wild.

Duplicate of T8936?

I confirm the Maxime Corteel patch to be working with PHPUnit 7.0.1 too.

I think this is sort of less bad/weird now, at least. You get a tokenizer instead, which is still empty, but you're prompted to "Type a repository name..." and the UI isn't this odd empty select thing anymore.

is there a chance that this problem will get fixed?
The change D17989 is already from May 2017 without any reviewer...

I believe the behavior of this UI should generally align well with what reasonable users might expect, now. In particular, /src/backend and /src/backend/ are now exactly the same in terms of actually resolving ownership, although the UI will continue to show you the value you entered (to avoid confusion where someone types /docs/README.md and the UI echoes back /docs/README.md/ and they have a reasonable concern that the path wasn't understood).

Probably better is to add pathIndex

See T13092; tangentially, it might be nice to render these stories more explicitly as "X added Y, removed Z (because Z is a subproject of Y, and objects may not be tagged with multiple mutual ancestors/descendant projects)", if some sufficiently terse phrasing can be found.

D19111 doesn't fix this in the general case, but should produce the desired behavior for most inputs such that the input is in the form [x](y) and y is the URI of a Wikipedia article.

The intent isn't unambiguous in the general case, consider: Blah blah (see also [x](y)).

Ah thanks!

The non-bold ones also open in a new tab.

Oh! Yes. Sort of.

Just curious, but is the bold effect intentional in the "No Encoding Relative" scenario?

After changes T13073, I am no longer able to reproduce this. That task has made some improvements and may have fixed whatever happened here.

It isn't currently retroactive: the fix is in transition logic and the transition just didn't trigger before.

Is this retroactive to builds in this half state prior to this commit and
deploy?

D19032 now renders D123 in text contexts (plaintext email) as D123 <https://dev.tyrellcorp.com/D123> instead of https://dev.tyrellcorp.com/D123.

D19030 marks this as fixed: it removes this documentation.