On Fri, Nov 29, 2013 at 11:02:55AM +0100, Lucas Nussbaum wrote: > On 28/11/13 at 21:04 +0100, Niels Thykier wrote: > > Release Goals > > ============= > > > > We discussed release goals in some depth at the recent sprint. > > > > The general consensus was that, whilst release goals have been useful > > in the past to introduce archive-wide changes, we should review > > whether this remains the case and whether the release team is really > > the right place to determine them. We intend to consult with the > > project on this point in due course.
> Indeed. To elaborate a bit more: > Release Goals are usually distribution-wide changes to Debian. We have had > release goals for a long time (see e.g. [1] about etch release goals, in > 2006). Release Goals seem to have several purposes: > - in the past, specific NMU rules applied to release goals. However, that > is no longer the case. It is already possible to NMU for any bug (including > wishlist ones) provided that reasonable advance notice and effort to > consult the maintainer is applied. I think that misstates the rationale for release goals. It was *always* possible to NMU for any bug "provided reasonable advanced notice and consultation". The point of declaring a release goal is that, for a distribution-wide change that touches many packages, following the standard SRU process where each upload requires a built-in waiting period significantly slows down progress. So having a relaxed NMU policy for recognized project-wide goals, allowing release goal NMUs to be done quickly as part of bug squashing parties, benefits the project by letting us reach these goals much more effectively. > - Release Goals kind-of define Debian's technical agenda. However, one could > question whether it's really the role of the release team to decide on > this, rather than the one of the project at large. Shouldn't this be > discussed the usual Debian way (= discussion on mailing list to gather > feedback and reach consensus on the global picture; then do-ocracy for > the smaller implementation details)? We're not talking about small implementation details. What do you propose as a mechanism for agreeing to a reduced NMU delay for archive-wide changes? The release team may not be the right way to get this done organizationally, but a strict consensus-driven process on debian-devel is also not realistic as we will never converge on a decision in a reasonable amount of time. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
