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

Re: DEP1: how to do an NMU

On Tue, Jun 03, 2008 at 11:51:02AM +0200, Frans Pop wrote:
> On Monday 02 June 2008, Bas Wijnen wrote:
> > > The fundamental thing we disagree on is that you think creating a
> > > patch and doing an immediate upload to DELAYED is an acceptable
> > > workflow for any kind of issue.
> >
> > Yes.  Not recommended, but certainly acceptable.  With a long delay, of
> > course.
> My basic point is that in some cases doing an NMUs at all is not the 
> correct way to get a change into Debian.

This can be the expectation.  However, if there is (unexpectedly) no
reply for a long time (whatever that means), then an NMU becomes the
correct way.

> > What would you recommend me to do?  Tell you about the problem and hide
> > the package for some time?
> Submit the patch to the BTS and wait for a reaction from the maintainer, 
> same as we've been doing for the past X years.

I would of course do that.  But you do indeed ask me to hide the
package?  And after, say, 3 weeks have passed and nothing happened
(which is unlikely, but possible), I can upload it to DELAYED/7?  Then
why couldn't I upload to DELAYED/28 in the first place?  Or must I wait

> > What is so special about the DELAYED queue that makes a package in
> > there different from a package on my local hard drive, waiting to be
> > uploaded in case the maintainer doesn't reply (or accepts it)?  What if
> > I schedule an at job to upload it?  Must I not tell you that the upload
> > will (if needed) be done by atd, and suggest that I will personally
> > come back to it?
> You must not upload it AT ALL. Not directly, not to DELAYED, not scheduled 
> in any way.

So you are saying that NMUs should be forbidden completely?  Even after
waiting for a month?  And after waiting for a year?  You must agree that
at some point, NMUs are acceptable?  What's wrong with making things
clear in advance and using DELAYED?  The fact that you don't expect the
upload to unstable to actually happen doesn't make it wrong to schedule
it, IMO.

> And he should also not find that, because he was on holiday for 2 weeks, 
> all kinds of incorrect fixes for minor issues have made it into the 
> archive just because he missed the DELAYED window.

My suggestion doesn't change anything in this respect.  All I want to
see is that the suggestion that using DELAYED is not allowed in some
cases should be removed[1].  If a maintainer is away for long enough,
then his packages _can_ be NMUed without the DELAYED queue *anyway*.

[1] Note that it's only a suggestion anyway; the text currently does say
    what I want, strictly speaking.

> Again: I'm not proposing that the above be the standard procedure, but it 
> should the the procedure that is followed for generally well-maintained 
> packages by active maintainers/teams, especially for native packages and 
> non-urgent issues.

For those cases, if the NMUer uses a long delay (and he should, also
according to the DEP), it is irrelevant if there is a package in the
DELAYED queue or not.

I'm not suggesting that people should upload to DELAYED in those cases,
I only want to make it explicit that it's no problem.

> Unless we completely abandon the concept of "maintainer of a package", 
> using DELAYED for just any random change for any random package as you 
> seem to want is just plain wrong.

Again, I don't want to suggest people to do it, only allow them.  The
only assumption behind this is that every package may be NMUd, if the
maintainer is inactive long enough (however unlikely that may be).

That is not "completely abandoning" the concept of maintainers, but it
is putting limits on it.  Which is exactly what NMUs are meant for.


I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://pcbcn10.phys.rug.nl/e-mail.html

Attachment: signature.asc
Description: Digital signature

Reply to: