Hi, On Mon, Nov 19, 2018 at 06:50:16PM -0500, Antoine Beaupré wrote: > Automatic unclaimer > ------------------- > > After an internal discussion about work procedures, a friend pointed me > at the [don't lick the cookie][6] article which I found really > interesting. The basic idea is that our procedure for work distribution > is based on "claims" which mean some packages remain claimed for > extended periods of time. > > [6]: https://www.benday.com/2016/10/21/scrum-dont-lick-the-cookie/ > > For some packages it makes sense: the kernel updates, for example, have > been consistently and dilligently performed by Ben Hutchings for as long > as I remember, and I myself would be very hesitant in claiming that > package myself. In that case it makes sense that the package remains > claimed for a long time. > > But for some other packages, it's just an oversight: you claim the > package, work on it for a while, then get distracted by more urgent > work. It happens all the time, to everyone. The problem is then that the > work is stalled and, in the meantime, other people looking for work are > faced with a long list of claimed packages. > > In theory, we are allowed to "unclaim" a package that's been idle for > too long, but as the article describes, there's a huge "emotional cost" > associated with making such a move. > > So I looked at automating this process and [unclaim packages > automatically][7]. This was originally rejected by the security team > which might have confused the script implementation with a separate > [proposal][8] to add a cronjob on the security tracker servers to > automate the process there. > > [7]: > https://salsa.debian.org/security-tracker-team/security-tracker/merge_requests/23 > [8]: > https://salsa.debian.org/security-tracker-team/security-tracker-service/merge_requests/2 > > After some tweaking and bugfixing, I believe the script is ready for use > and our new LTS coordinator will give it a try, in what I would describe > as a "manually triggered automatic process" while with figure out if the > process will work for us.
So I ran it asking it to unclaim packages which didnt see activity in
dla-needed.txt for more than 3 weeks. These are the results from running
./bin/review-update-needed --lts --unclaim 1814400
-libav (Hugo Lefeuvre)
+libav
last NOTE: 20180529: Just contacted some of the CVE reporters to ask for the
reproducers, CC-ed team ML.
that's Last-Update: 2018-09-22 12:04 (59 days ago)
AFAICS this is a legit unclaim. Hugo, would you mind to unclaim this?
-liblivemedia (Hugo Lefeuvre)
+liblivemedia
last NOTE: *doesnt have a date to it*
and there's not Last-Update.
Not sure what to do with it, Hugo?
-linux (Ben Hutchings)
+linux
and
-linux-4.9 (Ben Hutchings)
+linux
(here I think I would like to be able to whitelist this as Ben currently
always takes these packages.)
-nsis (Thorsten Alteholz)
+nsis
last NOTE: 20181110: waiting for email answer
so here the script is buggy, this should not have been unclaimed!
-openjpeg2 (Hugo Lefeuvre)
+openjpeg2
last NOTE: *doesnt have a date to it*
still there is last-update in the output and it says "Last-Update: 2018-11-19
19:02"
so I believe the script is buggy.
-qemu (Santiago)
+qemu
NOTE: 20181026: no fix yet for recent dsa issues, but start working on
NOTE: pending no-dsa issues
Technically correctly unclaimed (as last edit was 26 days ago), however
given the notes I think this should stay as it is.
-symfony (Thorsten Alteholz)
+symfony
NOTE: 20181110: patches ready, struggling with test suite, waiting for email
another bug in the script, this should not have been unclaimed.
Conclusion: the script has potential but is still too buggy ;)
--
cheers,
Holger
-------------------------------------------------------------------------------
holger@(debian|reproducible-builds|layer-acht).org
PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
signature.asc
Description: PGP signature
