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 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120907060807.ga7...@gaara.hadrons.org