I don't see this increasing storage usage - just shifting it. Right now because Phacility doesn't support LFS, all those large files are going straight into Git, which not only ends up on an EBS SSD, but also has to be cloned every single time which increases bandwidth usage. At least with LFS those costs are going to be from S3 (which I believe is cheaper than EBS SSD per GB), and bandwidth would be down as new clones no longer need to pull every version of a large file in the Git history.

I think the current state of things is:

This doesn't seem to have caused any issues.

(Another possibility is to add behavior to arc to control this.)

Maybe. Another possibility is to mark builds as "nonblocking" in some sense. There are some other open requests for defining "advisory" or "noncritical" builds where build failure doesn't cause the Buildable to report a failed result overall. If we end up adding this state to builds anyway, it probably makes sense to include a "Does Not Block Review" flag to the "Does Not Fail Buildable" / "Does Not Block Dependent Builds" / "Failure Is Totally Meaningless" / Whatever flags.

The harbormaster builds that we have running on revision creation can sometimes be rather slow; they're builds in our primary CI system, but with less of a priority than jobs in the submit queue. This will result in 10-30 minute delays for every revision in our monorepo. I understand the preference for only adding configuration settings when absolutely necessary, but since this may result in a significant time sink for any installs with expensive builds, is it worth keeping something around like differential.initial-state?

From T10109, we shouldn't make revisions "Buildable" to Herald if the update is an automatic update in response to a commit being discovered.

After all that stuff:

This is technically accurate but real awkward for humans:

A very rough version of this is now in master, but only active if phabricator.show-prototypes is on. These are some of the (substantial) remaining issues I'm aware of, and there are probably others:

@epriestley I've pinged you via pm about prioritization.

This is now in stable, and deployed here and to the Phacility production cluster.

An unusual case here is Herald rules which take the "Send me an email" action, and act "only the first time". Their current behavior will be to activate when the draft is created, have their mail killed later in the pipeline when the Editor declines to generate any, and then never fire again.

This is now deployed on this server, we'll see how it holds up. It won't promote to stable until next week, and I'd discourage anyone from picking it up right away.

In Mercurial, can a branch have some open heads and some closed heads?

See also PHI68.

This is resolved by the Ferret engine:

See Planning for information on planning and timelines.

Should be quick to implement.

I've landed the two scary migration changes (D18418, D18419) and deployed them here without any obvious issues arising. The actual effects here are:

And one more, also for Kotlin.

@epriestly I'd lost that connection, so reachability, it might appear.

@kfsone Are you aware of arc diff --only (briefly mentioned above -- "just generate a diff to look at in the web UI, without other slow/complicated steps")? How do you picture arc selfreview differing from arc diff --only?

@epriestley I think you under-estimate the potential and value of your own product.

The simplest way to approach this is probably to do double writes: start writing the new tables, switch readers over, stop writing the old tables.

See PHI14 for priority.

And one more.

This is now formally prioritized (see PHI14).

We've had two customers hit this (both for Kotlin, although a config workaround is available).