On Sat, 22 May 2010 09:32:02 -0700 tony mancill <tmanc...@debian.org> wrote:
> I sponsored the upload of a number of Jari's fixes. You state that > they were disruptive, but I'm wondering to whom. The uploads were to > delayed queues and the maintainer notified via the BTS, and in all > cases where the maintainer actually ACK'd the bug report or NMU, we > discussed the matter with the maintainer and/or removed the NMU from > the delayed queue. > > In most cases (it may be all for the packages Jari and I worked on), > the maintainers never responded whatsoever to bug reports that were > over a year old, nor to the intent to NMU, so in a sense they could be > considered them QA uploads. I.e., if a developer can't be bothered to > even respond to a bug in the Debian BTS, then the package is > essentially orphaned. Then the process, as I see it, would be for the person making the proposed NMU to file the bug to orphan the package instead, wait the length of time that the proposed upload would have waited in the delayed queue, or maybe a bit longer, and then make a QA upload (or adopt the package) without using the delayed queue. > Freshening the packaging to generic best > practices (or perhaps a better term is "defacto standards") - e.g. > going to the quilt source format (which changes almost nothing), > using a modern version of debhelper, freshening a debian/watch file, > or adding standard fields to debian/control - makes things easier for > everyone involved, whether it be Debian QA or the maintainer (should > he or she every opt to reengage). Those tasks are definitely QA tasks, not NMU IMHO - none of those tasks would warrant an upload by anyone except the maintainer, either alone or in combination. Any bug reports for such issues would be wishlist severity, even a broken watch file is minor at best, unless ALSO allied with a FTBFS or similar RC issue. Once orphaned, the maintainer can always re-adopt the package - just as easily as anyone else. If the person doing the NMU does not seek to be maintainer of the package concerned, I see no impediment to following the existing orphan&QA method. If there is a chance that the uploader can be added to Uploaders: for future maintenance, then it might as well be a case that the orphaning bug report is retitled ITA - the original maintainer could be preserved in Maintainer: or Uploader:. Maintainers who don't actively maintain their packages may well welcome a chance to hand off the package to someone else, when they finally get time to answer their BTS email. To me, the changes made in the uploads to which Anna specifically mentioned are not "minimal NMU's" but QA uploads. I've nothing against the changes per se, except that as we are preparing for Squeeze, those who do have time to make NMU's should do so for RC bugs and those who do QA work should do it as QA work. I wish I had the time to do RC NMU's myself, but right now that resource is lacking in my own case. To those who do have time, please work on RC NMU's and not QA uploads that pretend to be NMU's. > I view the "absolute minimal changes" NMU process as designed for (and > more appropriate for) actively maintained packages. That is, the NMU > process assumes that there is a developer on the other end who > actually maintains the package. In that case, use the process designed for packages that are not maintained - orphaning and QA. > I do agree that the work, all of > which were either FTBFS or transition-related, could have been > coordinated through Debian QA. FTBFS? If it was, why were the bugs not RC? These looked like bugs that might become FTBFS in a little more time but were not right now. That's QA work IMHO. > In hindsight that may have been a > better approach. I am interested to hear QA's perspective; is it QA > that finds the uploads disruptive? This may be too simplistic, but this is how I see the question: Non-RC bugs: ========== If the package is actively maintained (maintainer responds to BTS emails about an NMU), then if someone else is to make an upload, that is an NMU. (A busy maintainer who allows the NMU would presumably be open to either having the new person as Uploader or letting go of the package itself.) If the package is not actively maintained (specifically if the maintainer does not respond to the BTS & an orphan bug report), then the upload needs to be a QA upload before the non-RC bug can be fixed and other issues resolved. RC buggy packages: =============== If the bug report is RC, fix it as an NMU with no changes other than the specific fix for that bug - explicitly not making minor changes like adding / changing VCS fields in debian/control and without making major changes like bumping the version of debhelper. If a package with RC bugs is not lintian clean, that isn't something an RC NMU should seek to fix IMHO. If the package is in such a bad state that it needs lots of QA work as well, consider if the RC bug should be cloned against ftp.debian.org as an RM bug. If not, orphan the package and fix the RC bug and the other issues as a QA upload. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
pgpsAcsP4smoq.pgp
Description: PGP signature
