Re: Role of Release Goals (Was: Release sprint results - team changes, auto-rm and arch status)
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 <vorlon@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
Reply to: