[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

feedback on review-update-needed --lts --unclaim (Re: november report)



hi,

this reply is mostly about using the tool itself, see below. I will now write
another mail about the results from using it...

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.

first, thanks your work and the nice summary of it, Antoine!

second, I ran the script now and got results, running it as
"./bin/review-update-needed --unclaim" it removed these entries:

Package: openjpeg2
Claimed-By: luciano
Claimed-Date: 2018-02-04 21:47 (288 days ago)

Package: 389-ds-base
Claimed-By: fw
Claimed-Date: 2016-10-18 21:26 (762 days ago)
Last-Update: 2018-07-12 21:25 (130 days ago)

Package: libxml2
Claimed-By: carnil
Claimed-Date: 2018-09-02 19:46 (78 days ago)

which interestingly 'hit the spot' we've previously discussed internally on the 
freexian-LTS list: while we can define rules for paid contributors ('after X weeks 
we will unclaim stuff which has been claimed but not finished') we cannot really
impose such rules on voluntary LTS contributors, like luciano, fw and carnil here.

So, luciano, fw and carnil: are you ok with unclaiming those packages? Or is there 
some other course of action you would suggest here?

Then... I realised I need to run "./bin/review-update-needed --unclaim
--lts", doh and you can basically ignore my last two paragraphs (because
they dont apply to LTS, but I left them as the general question still
stands...

So, third, what did "./bin/review-update-needed --unclaim --lts" do? Too
much, so I ran (in a sid schroot where I have python3-humanfriendly
installed) this: "schroot -- ./bin/review-update-needed --lts --unclaim 3w"
and got:

[output and]
Traceback (most recent call last):
  File "./bin/review-update-needed", line 129, in <module>
    args.quiet or print("Claimed-By: {}".format(entry['claimed-by']))
UnicodeEncodeError: 'ascii' codec can't encode character '\xe1' in position 24: ordinal not in range(128)

(This only happens if I run ./bin/review-update-needed in schroot.)

However no changes were made.

Fourth, the order of entries in the output and in data/dla-needed.txt is
different, which is confusing and makes it harder to find entries, could
that be fixed?

Fifth, if a package is unclaimed, it would be good to include this in
the package related output (and not just in the summary in the end), so 
instead of for example:

Package: icecast2
Claimed-By: Abhijith PA
Claimed-Date: 2018-11-04 11:25 (16 days ago)
Last-Update: 2018-11-06 09:46 (14 days ago)

it would be nicer if the output were

Package: icecast2
Claimed-By: Abhijith PA
Claimed-Date: 2018-11-04 11:25 (16 days ago)
Last-Update: 2018-11-06 09:46 (14 days ago)
Unclaimed because last update was more than $timespan ago.

Six, I ran "./bin/review-update-needed --lts --unclaim 1814400" on
stretch and got useful output which I will summarize in another mail,
so that we have one thread about improving the tool and another about
unclaiming specific packages.


-- 
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


Reply to: