I'm pretty sure this is done now ;p

Closed by 9a98e8be06817055693671cfbe6917645171993e

This is all done now, except for swh.docs which is a special case.

so ardumont, just use:

ok, my nix setup conflicts!

As user:

pkg-config --debug libsystemd
no output option set, defaulting to --exists
Error printing disabled by default due to use of output options --exists, --atleast/exact/max-version, --list-all or no output option at all. Value of --print-errors: 0
Error printing disabled
Adding virtual 'pkg-config' package to list of known packages
Looking for package 'libsystemd'
Looking for package 'libsystemd-uninstalled'

thanks for the pointer !

The most recent update of the state of this task has shown a regression in the journal test coverage, which, per se, is not a big deal (just a few points). But it does raise the question of how, once we have attained whatever "minimum" coverage we are OK with, we monitor overtime that there is no regression. For instance, I think that code reviews should show to the reviewers how the submitted diff affects code coverage. Ideally, reviewers should be able to so if it has a net positive or negative effect on coverage, and take that into account in their review decisions. (Which is not to say we should never accept diffs that decrease code coverage—there might be reasons to do so. But it is a data point that would be useful for reviewers to see.)

In T1689#31540, @olasd wrote:

IMy suggestion was having *someone* trigger the merge with a comment on the diff, once the tests pass.

In T1689#31539, @zack wrote:

I'm not a fan of automated merging when the test suite passes. I think merging code from third parties should always be a manual step by someone. If it can be made a Web UI button, even better, if not we will just standardize to the local arc workflow, which I've recently documented in the wiki.

Thanks for the investigation @olasd.

(looks like Herald can't easily trigger on a comment, because that'd be too easy)

So, according to the fine manual (https://secure.phabricator.com/book/phabricator/article/differential_land/) the "Land Revision" button on the Phabricator user interface depends on setting up:

• Drydock repository automation : https://secure.phabricator.com/book/phabricator/article/drydock_repository_automation/
• Which depends on setting up Drydock working copies : https://secure.phabricator.com/book/phabricator/article/drydock_working_copies/
• Which depends on setting up Drydock hosts : https://secure.phabricator.com/book/phabricator/article/drydock_hosts/
• Which depends on Almanac : https://secure.phabricator.com/book/phabricator/article/almanac/