[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Too much disruptive NMUs

On Sat, 22 May 2010 09:32:02 -0700
tony mancill <tmancill@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

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

Attachment: pgpo4c7pGhHJ4.pgp
Description: PGP signature

Reply to: