See PHI860 and T13111. In the future, repository nodes may automatically gc/prune/repack. If they do, it may make sense to sort them to the bottom of the list so traffic is sent to them only if no other nodes are available, in order to minimize the impact that gc/prune/repack have on other activity.

PHI860 is a close variant of this and discusses periodically running git repack. Most concerns around git repack are likely similar to concerns around gc and prune.

D19637 doesn't actually improve this, but it brings us a step closer (since the logic is now in PHP and can be modified more easily to label symbols and add context).

Yes. The diff is a relatively small amount of the work I must do to respond to this issue: install ElasticSearch, configure it in the way you describe, reproduce the issue, write or apply a change, verify it actually fixes the problem, go read through the documentation enough that I'm confident the fix is the best available fix and that we've understood the issue reasonably well.

Even if I'd provide the diff?

(Just to set expectations, anything which isn't coming in through Support Pacts may take a very long time for us to get to.)

• D19634 allows reviewers to mark their own inlines as "Done" before they submit them. This addresses the case where you want to leave a non-actionable inline (like "This is much-improved.") but feel like leaving an inline like this is imposing on the author because they "must" check it off.
• D19635 marks the author's own inlines as "Done" by default. They may un-mark them if they prefer (e.g., actually want to leave themselves a TODO). This addresses the case where authors feel like they "must" check off every comment, so they either reply in two passes (one to submit; one to check off all their own replies) or avoid replying.

With D11419 implemented, is it possible to now allow Herald rules to be triggered on a cron (even a very simple 'daily' option would be good)?

contentID on Document should probably not be nullable. We can generate a Document PHID first, save the Content with the right Document PHID, then save the Document with the content ID. Deleted/moved/stub documents still have Content, I'm pretty sure -- oh, except we can't do, this because Content uses documentID, not documentPHID. So maybe kick the can down the road.

Oh, and also to the original use case, I'll at least add some kind of warning for this since "silently skip some patches" isn't a good behavior. I'm open to adding some other hint mechanisms on top of this later so linters can better pick which patch wins, but would like to motivate it with some specific, surgical examples. The original example, where one linter removes debugging code and one linter reformats it, is a good starting point: in this case, "remove" should have greater strength than "reformat" and we'd prefer to discard the reformat patch and apply only the removal patch.

I'll plan to make these changes:

I'm going to try to rewrite our linters to emit minimal fixes and try that
out. I do think that will make the conflicts nearly nonexistent.

I think adding the "requirements of a custom linter" and possibly also
adding verification of original text matching the byte range for fix
application should still be addressed, though.

After D19615, callers to harbormaster.sendmessage can specify "format": "remarkup" to get "details" rendered as remarkup (including {Fxxx}) instead of plain text.

The unit test results also don't currently show on individual builds, which is a little whack?

See T13189#240682 for some planning on the Unit Test result table.

See PHI710. This is a request for richer lint/unit results. It's likely entangled with T13088 but can probably be planned.

(Feature request with no support mana.)