My company was a loving user of Phabricator (local server!) for over 10 years. I still fondly remember the discussions here and talking through new applications, testing changes, and so much more. I know that the use of this tool permanently shaped hundreds of engineers' views on code quality, review, the software development lifecycle, and so on. It will be missed.

Thank you @epriestley and all of Phacility. Phabricator is a shining example of a well-engineered product that itself encourages better engineering processes and having fun while doing so. I had a great time learning and using Phabricator and it has left a big impact. I only wish I could have been more involved in the development and community. Wishing everyone the best!

@avivey: a few folks have started discussing collaboration in the #phabricator channel on libera.chat irc network.

Thank you @epriestley (and @btrahan, @chad, and others) for the great work done here!

I could not find in the documentation how are we supposed to set a value for a custom field of type "user".
In particular, I am looking at doing this: set the default value to the current user (the user creating the Maniphest task)

This is approximately working now, although the "button" is currently this mess:

See T13656 for followup.

Instances technically have a formal "Deleted" status -- but it isn't really used by anything, nothing ever puts them into that status, and there are no instances in that status. For consistency with existing CLI workflows, I'm going to rename this to "Destroyed".

A related issue is that I think nothing currently destroys S3 data. For most instances this isn't significant, but it isn't helping anything. This should likely be part of the database destruction step, although it can probably interact with the S3 bucket directly.

Since observed repositories version differently today, this strategy won't work -- but I can't come up with any valid reason to ever put a repository into a "write maintenance" mode anyway. I do imagine making observed repositories "replay" fetches into the push log (as though they were pushes) in the future, but that still won't make "write maintenance" on an observed repository meaningful, so it seems fine to just prevent putting non-hosted repositories into this mode.

A minor issue on the way to this is that calling synchronizeWorkingCopyBeforeWrite() with an omnipotent viewer will write to the WorkingCopyVersion table with a null userPHID, which shows as "Unknown Object" in the UI.

A useful maintenance operation for staging area repositories is to remove out-of-date staging refs: old diffs which have already landed. This is of some particular importance for large installs, since Git has a significant per-ref overhead for many operations until protocol v2: by the time a repository has ~50K refs, interacting with it in basically any way has become slow and cumbersome.

Sorry to hear that and hope everything is OK with you @epriestley.
I spent many hours learning from this high-quality code base.
Best of luck in whatever you do in the future.

D21668 should improve this behavior, although it's not an ideal or complete fix.

Was a pleasure, thank you for this project!

So long, and thanks for the fishes.

...this would need some kind of smarter scope guard...

I also can't get O_NONBLOCK to survive process exit on macOS. This is possibly because macOS is now zsh, and this RedHat bug suggests that zsh clears O_NONBLOCK:

arc may leave stdout/stderr nonblocking.

I'd be interested in collaborating with anyone who is interested in continuing community-supported maintenance of Phabricator.

secure002 and secure004 are likely easy to take out of service, since they're pure replicas.