salvaging packages, was Re: Lucas Kanashiro and Athos Ribeiro salvaged my package
Hi
On Mon, Apr 16, 2018 at 09:43:10AM +0200, Andreas Tille wrote:
[snip]
I remember that this discussion comes up quite regularly (no statistic
but to my feeling once a year). I'd love if we could give fix rules to
yes, yes, yes. I remember this conversation starting and fading every
year or so (maybe each release cycle?. It doesn't matter)
the process of salvaging a package (or am I missing that this was just
done). I think the preconditions should contain something like:
(
* RC buggy (mandatory feature for salvaging a package)
I'd put a note that discourages people from increasing the severity of
a bug to RC and then take over the package maintenance
or
* No uploads for > 365 days *and* lagging behind upstream
)
and
* Public attempt to contact the former maintainer (be it as
response to the RC bug or for instance CCed to debian-devel
list)
It should be also mandatory that the salvaged package gets Vcs-fields
pointing to salsa.debian.org to enable any interested person to
I'd go even further and require a specific workflow to be followed or a
choice between 2-3 workflows. (e.g. don't switch d/rules to cdbs, use
git)
contribute. The former Maintainer may not be removed from d/control.
If the salvage is done by a team that should be used as maintainer and
the old maintainer moved to Uploaders. The changelog owner of the
salvage upload should be added to Uploaders in any case to take over
responsibility for the work.
Opinions?
After the RC bug is open some time should be allowed to the maintainer to
act.
Just putting a number out there, 1 month after the package is removed from
testing _without_ activity in the bug from the maintainer process [1] could start.
On Mon, Apr 16, 2018 at 04:11:13PM +0800, Boyuan Yang wrote:
[snip]
Opinions?
I would suggest we exclude NMUs from "No uploads for > 365 days" requirement.
agreed
The person who want to salvage the package probably should also wait for two
weeks after initial public contact, then send another public email, wait for
another two weeks, send another public notification email before doing actual
salvaging efforts (moving packaging repo, uploading packages, etc). Idea
copied from QA/MIA process (https://wiki.debian.org/qa.debian.org/MIATeam).
[1] ^^
agreed, better to re-use established procedures
On Mon, Apr 16, 2018 at 10:26:08AM +0200, Philipp Kern wrote:
[snip]
copied from QA/MIA process
(https://wiki.debian.org/qa.debian.org/MIATeam).
I know that I am someone who also lacks time quite often. But still,
this kills a lot of velocity and I wonder how many people will be
motivated enough to follow up through a whole month of waiting. On the
other hand if that gives you a blanket "it's now yours, do with it as
you see fit, including taking over ownership", maybe that's not so
bad.
I think it strikes a balance, when you want to work on somebody else's
package you want to do it now, most likely, because you need the package
to be in good shape.
But at the same time you don't want to take a 2 weeks holiday without
computer to come back and find your packages under someone else's ownership
And still, 1-3 month is faster than a maintainer that may never come back
(There's of course also the question of VAC notices to crawl, though.
What if before going in a long VAC (we are potentially talking about
1 year) the maintainer opens a bug in all its packages signaling that
he won't be around for a year and that people should not take over
his packages.
That bug would open the door for 0 delay NMU
If someone went away for a longer period of time with an intent to
come back, it should be fair game to fix the package and own related
breakage but obviously not to just hijack it away from the original
maintainer.)
how do you know that person is coming back if it never announces it?
On Mon, Apr 16, 2018 at 09:58:59AM +0200, Tobias Frost wrote:
[snip]
Was mentioned on the salvaging packages BoF at Montreal: https://lists.debian.org/debian-devel/2012/09/msg00654.html
Besides the thread, are you aware of anything written down somewhere?
--
IRC: gfa
GPG: 0X44BB1BA79F6C6333
Reply to: