In D20110#251790, @epriestley wrote:

Do you think we should build T5953 before removing this? I worry that's a very large amount of work.

FWIW, I definitely used this import flow in a previous life and it worked for me. I'd like to have some other technique for bulk user creation before totally blowing this code away.

Long ago, passwords were digested with usernames as part of the salt.

In D20083#251386, @epriestley wrote:

...wherein the return value of fwrite() (in C) is ignored and str_len is returned unconditionally.

In D20083#251379, @epriestley wrote:

But, I still can't get it to do anything interesting when I SIGHUP it.

I can't get signals during fwrite() to do anything.

• fwrite() returns 0.
• stream_select() errors.
• The stream is legitimately in a dead/error/failures state and should not be retried.

That upstream bug report is really something else.

Nice.

I'm a little surprised that this would have a significant performance impact, but maybe I'm underestimating the amount of query string building we do.

I would kind of like to see these changes split into two diffs, but there's nothing wrong with reverting the whole thing if this causes problems.

Marking this as changes requested because I think the PhutilURI.php change is wrong.

Thanks for fixing this. When I get back let's make sure I can repro these cluster issues in my dev environment and update the docs (and/or finish my workflow script for automatically setting up all this state for dev environments, which is arguably better than documentation).

Ok I'm on board.

Oh, there's more context in D20044, hang on.

This change looks good, but what exactly does it accomplish? I feel like this would be useful if a user was trying to take an action that required MFA, but their account had no MFA factors configured, but is such a thing even possible? Otherwise this feels like a message that we train users to ignore whenever they see it.

FWIW I only read the last few comments on PHI1039, but I think I got the gist of this change. I definitely think we should merge the Maniphest and Projects subtype implementations before adding a third subtype Edit Engine, though. On the other hand, I'm not sure what object would be next in line to get the subtype treatment, so maybe this is all fine.

Also, BOY, this is a lot of code.

This is half-reviewed; more coming soon.

TIL.