I'm pretty sure this is done now ;p
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 6 2020
Aug 4 2020
Jul 16 2020
Jul 8 2020
Jul 7 2020
Apr 21 2020
Mar 14 2020
Mar 13 2020
Mar 11 2020
Jan 27 2020
Nov 26 2019
Closed by 9a98e8be06817055693671cfbe6917645171993e
Nov 22 2019
Nov 21 2019
This is all done now, except for swh.docs which is a special case.
Nov 19 2019
Nov 18 2019
Sep 6 2019
Sep 5 2019
Aug 29 2019
Aug 28 2019
Aug 27 2019
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'
Aug 6 2019
Aug 2 2019
Aug 1 2019
Jul 11 2019
Jul 5 2019
thanks for the pointer !
Jun 12 2019
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.)
May 25 2019
May 14 2019
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/
May 10 2019
Apr 24 2019
Apr 6 2019
Apr 2 2019
Mar 25 2019
Mar 24 2019
Mar 23 2019
Mar 6 2019
Closing this as I forgot it exists a configuration entry to force the serving of assets by Django (https://forge.softwareheritage.org/rCDFD7b3213293ca1670a738d540cbba05e87e5cf6042).
Feb 28 2019
This script is obsolete now that we migrated to git-buildpackage.
Feb 27 2019
Feb 25 2019
Feb 20 2019
Seems to be fixed since 2019-02-12.
Feb 14 2019
Fix indentation (missing 4 spaces)