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 <[EMAIL PROTECTED]>: ! 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. Cheers, FJP
signature.asc
Description: This is a digitally signed message part.
