On 06/01/14 at 12:59 +0000, Ian Jackson wrote: > Lucas Nussbaum writes ("Re: Delegation for the Release Team"): > > On 06/01/14 at 11:56 +0000, Neil McGovern wrote: > > > Explicitly again: Please see the last 7 years worth of bits mails, where > > > the release team have lowered this without advance notice, for BSPs etc. > ... > > First, I do not think that we have a NMU *policy*. What we have is a set > > of (non-binding) recommended procedures, including recommended delays, > > I think regarding our NMU policy as non-binding is a very bad idea. > NMUs are an important area of interaction between maintainers and > other contributors. Given the social contest, I think it is very > important that we have a clear understanding of what kind of NMU is > permissible when. Anything else is a recipe for people with different > understandings of the rules to end up arguing. > > Can you imagine the reaction of a maintainer team if an NMUer > justified a breach of the policy on the grounds that it's not binding > but only "guidelines" ? I think the reaction here on -devel would be > unfavourable too.
I agree with you that the NMU recommended practices must be clear, and leave little place for interpretation. I think that [1] is reasonably clear in terms of what's generally considered acceptable or not, even though there's always place for improvement. [1] http://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#nmu I disagree that we should have *rules* because, given the social context, I find it important to leave space to adapt to each case. For example, if I had a fix for #713183 (RC bug against pyg, opened on 2013-06-22, no action since then, no co-maintainer, maintainer looks inactive, popcon=3), I wouldn't have a problem uploading with a 0-day delay. If I thought I had a fix for #727786 (RC bug against eglibc, opened on 2013-10-26, last action on 2013-11-12, maintained by an active team, popcon=158880), I don't think that uploading with a 0-day delay would be a very good idea. Problem is, there are many cases between those extremes. If you turn the NMU recommended practices into rules, you could create or reinforce the feeling that 0-day NMUs are a perfectly valid option in both cases described above. > > I think that this part of developers-reference, like any part of > > dev-ref, can be changed by any DD, following a process similar to the > > one the release team used in 2011: > > > - the release team announced its intention to change the policy in > > > https://lists.debian.org/debian-devel-announce/2011/03/msg00016.html > > > - #625449 was filed against developers-reference > > > - there was some discussion > > > - the proposed change made it into developers-reference > > This is obviously impractical, for, for example, a BSP. > > > That is, propose a change and seek consensus. > > Given Lucas's attitude, I would like to suggest to the release team > that they file a bug against the the Developers' Reference, containing > a proposed change explicitly authorising the release team to vary the > NMU rules. That ought to satisfy Lucas's idea of the proper process > and put us back to the status quo ante. Do you see a problem with the current NMU recommended practices, that you would like to fix? I'm asking because the current ones have been defined 2.5 years ago, and I don't remember much discussion about them since then. Maybe we could save everybody's time, and have that discussion about who is allowed to change them when there's a change that someone wants to do. Also, I'm surprised that you didn't comment on the last part of my mail. Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140106142054.ga21...@xanadu.blop.info