This is an unconstructive mess that I don't specifically plan to act on. T13069 and other work may eventually resolve this case indirectly.

Currently, expected behavior.

Currently, if a card requires MFA to edit, we're unable to prompt the user. We likely should be able to do a prompt inline. This should also probably have a warning icon on the card itself.

D20196 removes this code.

(I'm not 100% sure that D19972 fixes this completely, but it appeared to locally. In the future, "Mail Stamps" should include this information in a more reliable format, although they do not currently include transaction information. See T13069.)

Presuming something fixed this.

In T12145#242682, @joshuaspence wrote:

I'm having some trouble getting this new behaviour (which IIUC basically means that multiple hosts in a Drydock pool should be load-balanced across). In "active resources" I see three Drydock hosts, which all belong to the same Almanac service. In "active leases", however, I see only a single host lease and many working copy leases.

I'm having some trouble getting this new behaviour (which IIUC basically means that multiple hosts in a Drydock pool should be load-balanced across). In "active resources" I see three Drydock hosts, which all belong to the same Almanac service. In "active leases", however, I see only a single host lease and many working copy leases.

I would like to add another use case where this would be beneficial.

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.