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

Re: Let's start salvaging packages!



On Sun, 29 Jul 2018 17:40:49 +0800, Tobias Frost wrote:

> tl;dr: Let's bring the package salvage process discussed some years earlier to
> life!

Indeed!
Thanks for picking up this topic.
 
> There will be a BoF at DebConf18 Thursday, August 2nd 11:00 in Room Xueshan [a]
> for dicussion and fine tuning. (We will likely have video coverage.)

I won't be there, so just some quick thoughts in advance:
 
> Reasons to salvage a package
> ----------------------------
> 
> A package is eligible for salvaging if it is in clear need of some love
> and care, i.e. there are open bugs, missing upstream releases, or there
> is work needed from a quality-assurance perspective; AND there is the
> need to upload the package to deal with these issues; AND at least one
> of these criteria applies:
> 
> * There is no visible activity regarding the package [c] for /six
>   months/, OR
> 
> * A previous NMU was not acknowledged, and a bug justifying another NMU
>   is pending for /one month/ [c,d], OR
> 
> * The last upload was an NMU and there was no maintainer upload within
>   /one year/, OR
> 
> * Bugs exist for more than one major missing upstream version and the
>   first bug is older than /one year/, OR
> 
> * The package blocks a sourceful transition for /six months/ after a
>   transition bug was filed against the package in question.

I think that's maybe a bit too complicated.
It all makese sense somehow in itself (and I guess I was involved in
coming up with these conditions some years ago) but reading it I have
the impression that I'll never remember it and will have to very
carefully and concentrated re-read it in every case where I might
want to salvage a package and hope that I get the result of several
ANDs and ORs right.
 
> Procedure to salvage a package
> ------------------------------
> 
> If the criteria described above are fulfilled, anyone interested can
> start the following salvage procedure.

This looks good in general.
 
> 3) The upload replacing the former maintainers of the package can be
> made can be prepared already after 21 days, but needs to go to
> DELAYED/7.  The salvage bug should be closed by the upload and an
> nmudiff sent to the bug. The nmudiff should also explictly CC the
> maintainer, the packaging team and all uploaders.

Totally minor point: Why the nmudiff?


Another thing that came to my mind is:
The proposal talks (also in the last quoted paragraph) about
"replacing the former maintainers"; what I in practice would like to
do usually is to move a package which is under-maintained and has a
single individuum in Maintainer to a team, with or without keeping
this person in Uploaders. (I've also seen cases where the person is
already a member of the team but maintains (or neglects) packages
outside.)
Maybe this is not relevant as it's covered by "changing the Maintainer
field"; or maybe it is because it allows the future ex-maintainer to
still work on the package, together with others in a team? Or maybe
I'm just making things more complicated when I was asking for simpler
guidelines before :)
 

Thanks again for working on this, and a successful BoF in some hours!


Cheers,
gregor



PS: Some nightly thoughts, not relevant for the BoF per se:


Semi-radical proposal
---------------------

"Salvaging a Package, the simple version"

If a package is apparently un(der)-maintained (e.g. RC bugs without
reply, several NMUs in a row, etc.) it can be salvaged, i.e. the
maintainership transfered to another person or team.

An ITS (Intent to Salvage) bug is raised against the package stating
the intent. If the bug is closed by the maintainer or an uploader,
the process is finished.
Otherwise, after 1 month, the package can be taken over by a new
maintainer person or team.

= Less radical variant =

If a package, which falls into the area of competence of a packaging
team, is apparently un(der)-maintained (e.g. RC bugs without
reply, several NMUs in a row, etc.) it can be salvaged, i.e. the
maintainership transfered to the respective team.

An ITS (Intent to Salvage) bug is raised against the package stating
the intent. If the bug is closed by the maintainer or an uploader,
the process is finished.
Otherwise, after 1 month, the package can be taken over by the team;
the previous maintainer is kept in Uploaders and invited to join the
team and help in the maintenance of the package.



Radical proposal
----------------

Q: What is the worst that could happen if there was no package
ownership in Debian?


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Trio Infernal: bottle of wine

Attachment: signature.asc
Description: Digital Signature


Reply to: