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

Re: Improper NMU (Re: NMU for libquota-perl)

Elie Rosenblum <fnord@cosanostra.net> writes:

> On Mon, Sep 02, 2002 at 02:25:30AM +0100, Colin Watson wrote:
> > On Sun, Sep 01, 2002 at 09:19:17PM -0400, Elie Rosenblum wrote:
> > > On Mon, Sep 02, 2002 at 02:16:11AM +0100, Colin Watson wrote:
> > > > Technically it wasn't. The upload is still in the DELAYED queue, which
> > > > is really just a convenient automated way of saying "I'll NMU this
> > > > package in <n> days if I don't hear anything", with the added bonus of
> > > > allowing the maintainer to poke at it and see exactly what would go in
> > > > in the absence of a maintainer upload. I usually explain this when using
> > > > the delayed queue.
> > > 
> > > I assume you also submit a bug.
> > 
> > Quite.
> Would you agree that performing an NMU without a BTS entry is wrong?
> > > Do you generally do this without leaving a bug for a few days first?
> > 
> > In the case of the perl transition I've been given to understand by the
> > actions of other developers that the -devel-announce post on 31st July
> > was enough. Otherwise no.
> I see.
> Well, I disagree with this (as do I believe some others), but only
> in that no NMU should be done until the bug has existed for a few
> days (if nothing else, this addresses the distinct possibility of
> NMUs actually breaking stuff, which has already been brought up in
> this thread). I'm probably not going to convince you of this, any

The Bug existet since 31st July even if it wasn't formaly in the BTS
against your package.

> more than you will convince me that I'm wrong here. I have not,
> however, been hit with this general case...I've been hit with an
> irresponsible maintainer performing an NMU without submitting a
> bug at all, even if it was 5 minutes before he uploaded. This is
> just plain wrong, and something that can cause us really serious
> problems if people start to imagine that it's acceptable - 
> especially since we have little control over which keys can
> successfully upload any given package.

In the case of something so trivial as causing a recompile for a
problem that has been known for some time the warning given by the
delayed upload should be enough.

Do we realy need to mass-file bugreports for this? Thats the
alternative to mentioning something like the perl transition on -devel
and then fix it in a group effort some time afterwards.

You might have a point in general but not in this case.

Just my 2c of though, don't blame anyone else.

Reply to: