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

Re: DEP1: how to do an NMU

On Monday 02 June 2008, Bas Wijnen wrote:
> > Basically I and several others have been asking to add something that
> > effectively (and more explicitly than in the current proposal) says:
> >
> >    Please consider before you NMU if just contacting the maintainer
> > isn't likely to more effective than doing an NMU.
> >
> >    In general it should be considered preferable that a maintainer
> >    takes care of an issue himself and that he is given the chance to
> >    review and correct your patch, because he can be expected to be
> > more aware of corner cases and complex interactions, things that an
> > NMUer might miss.
> While I agree with this principle, I have one comment: IMO posting a
> patch (with explanation of what it fixes and why, and that an NMU to
> DELAYED has been uploaded) to the BTS is an appropriate way to notify
> the maintainer.

Right. And this is where we fundamentally disagree.

> I find this important for fixing mass-filed-bugs.  They're all similar,
> the solutions probably are as well, and it would be too much (IMO)
> overhead to have to check who is maintaining the package.

I have no real problem with what you suggest in _this_ use case, and the 
changes that Lucas has made to the DEP do _not_ prevent doing this.

The only thing the changes are intended to do is to make the NMUer think 
twice about doing a direct NMU without doing the "normal" thing of 
submitting the patch in the BTS and giving the maintainer a chance to 
respond without forcing his hand and forcing him to reorder his 
priorities by doing a simultaneous upload to DELAYED.

> This is only about bugs which have had the "intent to NMU" in the BTS
> for some time before the upload hits unstable.  I explicitly do want to
> allow (and not discourage) uploading to DELAYED at the same time as
> reporting the bug in the BTS, even for active teams.

I do, and if you are not willing to compromise on this I doubt there is 
ever going to be consensus on this DEP. Not for all cases, but I see no 
reason why that should become the "normal" practice for *all* packages 
and for all *bug* severities and for *all* types of bugs.

Consider again Debian Installer. D-I is native code. This means that every 
upload is effectively a new upstream release. What you are proposing is 
to let random people do upstream releases without first discussing their 
changes with the upstream maintainer.

My second main objection was this <200805312102.18976.elendil@planet.nl>:
! The DEP should not be a licence to avoid entering into a discussion with
! the maintainer of a package, or to pre-empt him.

From my PoV your standpoint is that you _do_ want to give developers that 
licence and for me that is unacceptable.

To be totally clear: I do think the policy you are proposing makes sense 
for some cases and should be possible. But there are also cases where the 
current practice of just submitting your patch to the BTS and having the 
maintainer handle the rest of the process should remain the normal 
procedure, and the DEP should reflect this.

I agree with Lucas that general texts are to be preferred over listing 
maintainer activity or teams or native packages as special case 
exceptions. And I do feel that my concerns have been sufficiently 
addressed with the recent changes.


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: