Bug#681833: developers-reference: please document a package salvaging process

[Guillem Jover]

Hi!

On Mon, 2012-07-16 at 18:35:33 -0400, Michael Gilbert wrote:
> package: developers-reference
> severity: normal
> version: 3.4.8
> tag: patch

> I've prepared an initial draft of a developers reference patch that
> would document a package salvaging process.  Please see below.

Bart has already covered some other parts which I agree with, I just
wanted to expand on some of the proposed changes.

> --- pkgs.dbk.orig 2012-07-16 18:19:56.065047490 -0400
> +++ pkgs.dbk  2012-07-16 18:32:20.626439544 -0400
> @@ -2257,6 +2257,86 @@

> +
> +Also, at times, there can be situations where contributors would like to 
> modify
> +a package for a lower severity bug report, but said bug is ignored for a long
> +time by an active maintainer.  If the fix is good, it should certainly go 
> into
> +the archive.  This is another case where an NMU is appropriate, but it would
> +not be considered a liberal NMU.  These cases can be resolved by are a 
> standard
> +10-day NMU, and conflicts can be refered to the technical committee as a
> +technical dispute.
> +

> +
> +The liberal NMU is also appropriate in general for fixing bugs, but for 
> packages
> +that have not recieved an upload in greater than six months liberal NMUs are
> +highly encouraged and can fix issues that are not tracked in the BTS.  
> Changing
> +the build system in a Liberal NMU is still not acceptable, but all other 
> changes
> +are allowed including packages of new upstream versions.
> +

Maybe it's just me, but my first assumption when confronted with a “lower
severity” bug from a known active maintainer, which has gone unanswered
(even if it has got a patch) is that either:

 a) There's something that needs (further) (lengthy) investigation.
 b) A fix might seem trivial but it's not: might need major work like
a coordinated transition, might cause breakage elsewhere, the patch
might be misdesigned or wrong, etc.
 c) There's been more important or urgent things the maintainer has had
to deal with (this might include reading a book or going to the
beach too! happy maintainers are better maintainers).
 d) The maintainer might prefer to queue a bunch of changes instead of
doing single item uploads.
 e) Something else.

And my first reaction, if for whatever reason the bug is relevant or
important to me, would be:

 1) If the bug seems trivial or obvious enough to me:
- Try to diagnose the problem or provide a way to reproduce it,
  if that's still missing.
- Try to provide a patch, if there's none.
 2) Otherwise, ask (if no one did before) on the bug report if the
maintainer has done some investigation or started working on a
fix already; might need help tracking it down, testing a patch,
coordinating or getting a transition done, or implementing a fix;
or if the bug has a patch on it, ask if the maintainer would ack
it or required upstream to ack it, and suggest if an NMU might be
of help, by offering to prepare it and handling any aftermath.
 3) If the bug is extremely important to me, or maybe I feel like it
that day, try to get acquainted with the code base, or learn the
programming language, etc; then goto (1).
 4) _Patiently_ wait; goto (3) after some time or goto (2) but
certainly not before at least several months or more have passed
(i.e. “Do not pester nor whine”).

In addition, not all bugs are made equal. For some it seems to me NMUs
are the right tool if enough time has passed, those would include
segfaults, crashes, build failures, data loss, security issues, policy
violations, etc, in general what would apply for most RC bugs. Some
others of lower severity seems to me can also be fine for NMUs too,
like translation updates, typo fixes, patches cherry picked from
upstream, even new upstream releases (as long as the maintainer has
not stated explicitly there might be problems with packaging such
newer version).

But other classes of bugs I strongly think should be considered off the
table if the maintainer has not acked them, because if supposedly NMUs
are a tool to help the maintainer (as it has been promoted in recent
times, to make them more widely accepted) then imposing on the
maintainer for example a delta from upstream when the maintainer might
have a zero-divergence policy would not be acceptable, less so if it
ends up being rejected by upstream, in which case it's much more work
for the maintainer. Full disclosure, I've never had any issue with
diverging greatly from upstream, but then I'm the one deciding what
future work I'm imposing on myself, and knowing one's upstream also
helps in predicting what solution or implementation has chances of
being accepted.

So, I strongly disagree with this liberal NMU concept for active
maintainers. And for inactive maintainers, there's already the MIA
process.

> +
> +A mail for each Liberal NMU should be sent to either the maintainer or the 
> BTS
> +(which is automatically forwarded to the maintainer) and should 

Bug#681833: developers-reference: please document a package salvaging process

[Jakub Wilk]

* Bart Martens , 2012-07-17, 06:52:

ftpmaster doesn't remove packages without good reason.


Sure they do.

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#681833: developers-reference: please document a package salvaging process

[Bart Martens]

On Mon, Jul 16, 2012 at 06:35:33PM -0400, Michael Gilbert wrote:
> I've prepared an initial draft of a developers reference patch that
> would document a package salvaging process.  Please see below.

Hi Mike,

I'm not convinced that we need an additional procedure for package salvaging
because we already have procedures addressing that.  I suggest that you propose
improvements to the existing procedures if you want them improved.  I also
doubt that some things you propose are improvements.  I comment in detail on
your patch:

> +
> +Package Salvaging
> +
> +
> +Unfortunately over time, certain maintainers become less active without 
> turning
> +over their packages via the orphaning process or fully leaving the project.
> +This is a natural process, and there is nothing wrong with it, but in the
> +meantime their packages suffer bit-rot

Anyone interested can prevent such bit-rot via NMU.
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu

> and bug reports go unanswered.

Anyone interested can answer bug reports.

> +Fortunately the NMU process provides a means to inject much needed health 
> into
> +these neglected packages.

Yes, the NMU procedure already addresses that.

>  This is the liberal NMU.

If you want the NMU procedure to allow more "liberal" changes then I suggest
that you propose a change to the NMU procedure:
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu

> +
> +
> +
> +Also, at times, there can be situations where contributors would like to 
> modify
> +a package for a lower severity bug report, but said bug is ignored for a long
> +time by an active maintainer.

If the maintainer has no time to answer the bug report, then anyone interested
can answer the bug report and/or update the package via NMU.

>  If the fix is good, it should certainly go into
> +the archive.

Not without permission from the active maintainer.  The NMU procedure allows
the active maintainer to object against the NMU.

>  This is another case where an NMU is appropriate, but it would
> +not be considered a liberal NMU.  These cases can be resolved by are a 
> standard
> +10-day NMU,

The NMU procedure already mentiones delays and also the use of the DELAYED
queues.

You seem to propose that anyone can just go ahead with uploading NMUs in
DELAYED/10 for fixing lower severity bug reports ignored by an active
maintainer.  I object against that.

> and conflicts can be refered to the technical committee as a
> +technical dispute.
> +

This is obviously already described elsewhere.

> +
> +
> +Ideally, the liberal NMU is done by uploading the package of interest to the
> +DELAYED/10 queue or greater.
> +

So far your term "liberal NMU" seems to mean "any fix anyone feels as a good
fix".  If your proposal would be that "anything goes via DELAYED/10 queue or
greater", then I would absolutely object against that.

If you want to describe in more detail when the DELAYED/10 queue can be used
for NMU's, then I suggest that you propose changes to the NMU procedure.

> +
> +
> +The liberal NMU is also appropriate in general for fixing bugs, but
> for packages
> +that have not recieved an upload in greater than six months liberal NMUs are
> +highly encouraged and can fix issues that are not tracked in the BTS.  
> Changing
> +the build system in a Liberal NMU is still not acceptable, but all
> other changes
> +are allowed including packages of new upstream versions.
> +

You seem to propose a change to what is allowed via NMU.  Such changes clearly
belong in the text of the NMU procedure, not in a separate text.

> +
> +
> +A mail for each Liberal NMU should be sent to either the maintainer or the 
> BTS
> +(which is automatically forwarded to the maintainer) and should include a
> +hyperlink to a VCS containing the changeset of this liberal NMU and all of 
> your
> +prior liberal NMUs to this package.  A VCS link is preferred to
> +an NMU patch in these cases since long-term if the maintainer does not
> +resume activity, you will be making many liberal NMUs and ultimately becoming
> +its maintainer.  The message body should maintain a positive
> +attitude and mention that the maintainer may review and has the option to
> +cancel the NMU while it waits in the upload queue for the next 10 or more 
> days.
> +

The NMU procedure describes that "you must send a patch with the differences
between the current package and your proposed NMU to the BTS".

A VCS link is, in my opinion, not preferred.  If the maintainer no longer
maintains the package, then we already have this procedure:
http://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#mia-qa

And you seem to repeat that a "liberal NMU" can go in the DELAYED/10 queue.

> +
> +
> +Unfortunately the maintainer may reject some of your contributions that you
> +disagree with.  In this case, try to find a way to implement the changes in a
> +way that the maintain will approve.

That is already part of the NMU procedure.

>  Fa

Bug#681833: developers-reference: please document a package salvaging process

[Russ Allbery]

Michael Gilbert  writes:

> Just to give you an idea of what I'm thinking long-term: salvaging will
> one day obsolete MIA.  If maintainership changes become self-directed,
> then ultimately there is no longer a need for a MIA team to pester
> people (which no one wants to do anyway).  MIA'ness will be clear once
> new maintainers have taken over all of the old maintainer's packages and
> removed his name.  That would then give MIA the go-ahead to say hey, all
> of your packages have been salvaged, we'll be closing your account soon
> if no action is taken.

The other half of the replacement for MIA would be the periodic WAYT pings
(hopefully that's still a plan to do that ongoing) to confirm that people
still want to be active in the project.  Just because someone has no
packages doesn't mean that we should close their account; they're still
entitled to vote for as long as they wish, IMO.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#681833: developers-reference: please document a package salvaging process

[Michael Gilbert]

On Mon, Jul 16, 2012 at 9:37 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>
>> Interesting condition.  According to Developers Reference 5.9.4,
>> orphaning is a process that is only supposed to be initiated by the
>> existing maintainer.
>
> Orphaning is also done by the QA team, and it's frequently been done by
> other people after discussion in debian-devel provided that the same sorts
> of checks have been done.  (Membership in the QA team is not well-defined,
> so to some extent that's the same thing.)

Thanks for the correction.  3.1.3 does grant that power to the QA
team, which is of course effectively all DDs.

Although once salvaging is in place, and there is a self-directed way
to adopt packages, the need to do orphaning beforehand won't be
necessary.  So then orphaning as a maintainer-only right just makes
more sense.

Just to give you an idea of what I'm thinking long-term: salvaging
will one day obsolete MIA.  If maintainership changes become
self-directed, then ultimately there is no longer a need for a MIA
team to pester people (which no one wants to do anyway).  MIA'ness
will be clear once new maintainers have taken over all of the old
maintainer's packages and removed his name.  That would then give MIA
the go-ahead to say hey, all of your packages have been salvaged,
we'll be closing your account soon if no action is taken.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#681833: developers-reference: please document a package salvaging process

[Russ Allbery]

Michael Gilbert  writes:

> Interesting condition.  According to Developers Reference 5.9.4,
> orphaning is a process that is only supposed to be initiated by the
> existing maintainer.

Orphaning is also done by the QA team, and it's frequently been done by
other people after discussion in debian-devel provided that the same sorts
of checks have been done.  (Membership in the QA team is not well-defined,
so to some extent that's the same thing.)

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#681833: developers-reference: please document a package salvaging process

[Michael Gilbert]

As a reminder to myself if these changes were to gain traction,
section 5.9.5 (adopting a package) will also need some rewriting since
certain instructions overlap salvaging.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#681833: developers-reference: please document a package salvaging process

[Michael Gilbert]

On Mon, Jul 16, 2012 at 6:55 PM, Jakub Wilk wrote:
> * Michael Gilbert, 2012-07-16, 18:35:
>
>> +
>> +If a package has been already been orphaned, you may salvage it without
>> any
>> +kind of approval.
>> +
>> +
>> +
>> +Filing a removal request against ftp.debian.org, then reintroducing the
>> package
>> +with yourself as the maintainer is considered adversarial and is
>> explicitly
>> +disallowed.
>> +
>
>
> Is orphaning the package and then uploading it with maintainer set as
> yourself okay or is it "considered adversarial and is explicitly
> disallowed"?

Interesting condition.  According to Developers Reference 5.9.4,
orphaning is a process that is only supposed to be initiated by the
existing maintainer.

So yes, that would also be disallowed.  Since you are not yet the
maintainer, you cannot orphan the package in order to become the
maintainer.

I would probably go ahead and merge the removal and orphaning
statements together as a change to the above patch.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#681833: developers-reference: please document a package salvaging process

[Jakub Wilk]

* Michael Gilbert , 2012-07-16, 18:35:

+
+If a package has been already been orphaned, you may salvage it without any
+kind of approval.
+
+
+
+Filing a removal request against ftp.debian.org, then reintroducing the package
+with yourself as the maintainer is considered adversarial and is explicitly
+disallowed.
+


Is orphaning the package and then uploading it with maintainer set as 
yourself okay or is it "considered adversarial and is explicitly 
disallowed"?


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#681833: developers-reference: please document a package salvaging process

[Michael Gilbert]

package: developers-reference
severity: normal
version: 3.4.8
tag: patch

Hi,

I've prepared an initial draft of a developers reference patch that
would document a package salvaging process.  Please see below.

Best wishes,
Mike

--- pkgs.dbk.orig   2012-07-16 18:19:56.065047490 -0400
+++ pkgs.dbk2012-07-16 18:32:20.626439544 -0400
@@ -2257,6 +2257,86 @@

 

+
+Package Salvaging
+
+
+Unfortunately over time, certain maintainers become less active without turning
+over their packages via the orphaning process or fully leaving the project.
+This is a natural process, and there is nothing wrong with it, but in the
+meantime their packages suffer bit-rot and bug reports go unanswered.
+Fortunately the NMU process provides a means to inject much needed health into
+these neglected packages.  This is the liberal NMU.
+
+
+
+Also, at times, there can be situations where contributors would like to modify
+a package for a lower severity bug report, but said bug is ignored for a long
+time by an active maintainer.  If the fix is good, it should certainly go into
+the archive.  This is another case where an NMU is appropriate, but it would
+not be considered a liberal NMU.  These cases can be resolved by are a standard
+10-day NMU, and conflicts can be refered to the technical committee as a
+technical dispute.
+
+
+
+Ideally, the liberal NMU is done by uploading the package of interest to the
+DELAYED/10 queue or greater.
+
+
+
+The liberal NMU is also appropriate in general for fixing bugs, but
for packages
+that have not recieved an upload in greater than six months liberal NMUs are
+highly encouraged and can fix issues that are not tracked in the BTS.  Changing
+the build system in a Liberal NMU is still not acceptable, but all
other changes
+are allowed including packages of new upstream versions.
+
+
+
+A mail for each Liberal NMU should be sent to either the maintainer or the BTS
+(which is automatically forwarded to the maintainer) and should include a
+hyperlink to a VCS containing the changeset of this liberal NMU and all of your
+prior liberal NMUs to this package.  A VCS link is preferred to
+an NMU patch in these cases since long-term if the maintainer does not
+resume activity, you will be making many liberal NMUs and ultimately becoming
+its maintainer.  The message body should maintain a positive
+attitude and mention that the maintainer may review and has the option to
+cancel the NMU while it waits in the upload queue for the next 10 or more days.
+
+
+
+Unfortunately the maintainer may reject some of your contributions that you
+disagree with.  In this case, try to find a way to implement the changes in a
+way that the maintain will approve.  Failing that, please refer the matter as a
+technical disagreement to the technical committee.
+
+
+
+Preferably, after you have demonstrated that you can handle the package, the
+maintainer will either step down or approve you to be a part of the packaging
+team.  If the maintainer has been active or not approved this after an
+additional six months after your first liberal NMU, you may petition the tech
+committee to rule on the maintainership of the package.  Please include as much
+information as possible (including bug reports, uploaded versions, VCS links,
+etc.) to make the committee's decision easy.  If the maintainer at some point
+becomes active, and does not want your participation to continue, you may
+petition either accept that request and step down or petition the tech
+committee to rule on the matter.
+
+
+
+If a package has been already been orphaned, you may salvage it without any
+kind of approval.
+
+
+
+Filing a removal request against ftp.debian.org, then reintroducing the package
+with yourself as the maintainer is considered adversarial and is explicitly
+disallowed.
+
+
+
+
 

 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org