On 30/11/13 at 22:07 -0600, Steve Langasek wrote: > On Sat, Nov 30, 2013 at 05:40:35PM +0100, Jakub Wilk wrote: > > * Steve Langasek <vor...@debian.org>, 2013-11-29, 12:01: > > >What do you propose as a mechanism for agreeing to a reduced NMU > > >delay for archive-wide changes? > > > My proposal is to realize that reduced delay for archive-wide > > changes is not needed. > > > Seriously, such changes will take months or years anyway, so what > > does reducing a 10-day delay buy you? > > It buys you being able to finish in months, instead of in years. > > It buys you not having to track dozens of in-flight NMUs in parallel, > letting you spend more of your time working on improving Debian instead of > doing paperwork.
I fully agree that project-wide improvements should be encouraged, and that we should try to reduce the burden for people working on such tasks. So we need a efficient mechanism to protect such project-wide improvements to be blocked by a maintainer's unresponsiveness/inactivity blocks. However, on the other hand, the NMU process is disruptive for active maintainers, as the NMUer usually doesn't have insider knowledge of the package and its life cycle. So, it's really a question of how efficient we want the process to be, and how much we are willing to pay for that (in terms of disruptiveness). The current NMU rules allow someone to prepare a patch, file a bug with it, and upload to DELAYED/10, all in one go. The tracking needed for such a process is minimal, and the BTS, or BTS+UDD, likely can make it even easier. I agree that the 10-day delay might not be sufficient for transitions that require numerous stages, but in that case, I would totally understand if someone argued for DELAYED/5, especially if advanced notice is given (by listing all packages affected by a large-scale change). > It sets an appropriate project-wide expectation that certain NMUs are > sanctioned, so people (including new developers, NMs, or new contributors) > will feel supported in working on such tasks instead of being afraid to > stick their necks out. The need for review and feedback is another problem. It's often difficult to get feedback on a proposed change inside Debian. But I really don't think that it should be the release team's job alone to decide which project-wide improvements are good or bad. If it's too hard to reach consensus on -devel@ on a proposed improvement, I would rather prefer if we used the TC's ability to "offer advice". 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/20131201161735.gc28...@xanadu.blop.info