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
Attachment:
signature.asc
Description: PGP signature