Bug#681833: developers-reference: please document a package salvaging process
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 @@
> +<para>
> +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.
> +</para>
> +<para>
> +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.
> +</para>
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.
> +<para>
> +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.
> +</para>
I disagree a VCS link should be preferred (I think it's obviously fine
as an optional addition though), patches should go to the BTS, where
they cannot be lost, those VCS can (and tend to) disappear or get
relocated over time, and the normal way to review stuff anyway is
through patches not remote branches.
> +<para>
> +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.
> +</para>
There appears to be this relatively recent, continued and increasing
trend in some parts of the project to switch to some kind of autocratic
regime, instigated by some to give life to the tech-ctte, turn it into
an interventionist body, and make forceful resolutions a trivialized
day-to-day thing which the project should be somehow proud and happy
about. It's not clear to me if this is just a cultural thing or
particular to some of the individuals pushing for this, but escalation
to this kind of body and the subsequent forceful resolutions are very
confrontational and polarizing, or superfluous if agreement has emerged
elsewhere. Not to mention that being continuously given “direction”
(technical or otherwise) from up there by the “authority” feels
rather insulting.
To me this is a very sad and concerning trend... that I'd like and
I'd expect (?) the project to eventually reject, once enough people
have either been alienated and/or left in disgust, so that we can go
back to the previous decentralized and organic self-organizing way of
doing things; in the same way the excess of GRs in the recent past
got stopped. Although I've to say I'd rather see the project decide
extreme or globally reaching controversial cases through GRs than
through the tech-ctte.
And just to be clear my current position on this is not a direct
consequence of the multi-arch “overruling”, I've had this opinion
for a very long time now; just one recentish example:
<http://lists.debian.org/debian-ctte/2010/04/msg00005.html>
> +<para>
> +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.
> +</para>
Here it seems to me you are proposing as an acceptable outcome that
the current maintainer would end up having to work with the person
escalating the forceful inclusion of co-maintainership to the tech-ctte.
Either that, or trivializing taking over maintainership by force.
Having to “work closely” with people who have taken you to the tech-ctte
is already extremely annoying, displeasing and demotivating; and I think
being forced to work with them on a team when that was not the case
before would reach a new level of affront. And again it probably is just
me, but I think the right and respectful way to get into an existing
“team” (if no other procedures are in place) is by invitation, not by
forcing oneself in.
regards,
guillem
Reply to: