Re: Debian development and release: always releasable (essay)
Paul Wise <pabs@debian.org> writes:
> On Fri, May 10, 2013 at 3:49 AM, Lars Wirzenius wrote:
>> * Keep testing free of RC bugs.
> I keep packages I (co-)maintain free of RC bugs.
The point isn't what individual developers do, particularly developers who
are extremely well-engaged with the project. The point is to find ways to
do this at another level up. Obviously, given the number of RC bugs that
we had to fix *after* the freeze, this isn't already being done at the
level required for a timely release process. I don't think we can solve
that problem by saying "well, developers really *should*."
>> * We should limit the number of packages we strongly care about for
>> a release.
> I don't agree with this.
Care to expand the thought?
>> * Remove RC buggy packages sooner rather than later. An RC buggy
>> package should be removed at soon as possible: when the bug
> The release team already do this using a semi-automated method.
But by and large they only do this on a large scale during the freeze, at
which point, in a way, it's too late. We've already built a huge backlog
of work, and everyone is anxious to release. I think we should be doing
this continuously during the release and much more aggressively than we've
been willing to do in the past.
I suspect, though, that mini-freezes whenever the RC bug count rises above
a certain level will be as effective or more so, since I know that package
removal very quickly involves deeply tangled dependencies, and one has to
sometimes remove vast swathes of packages to remove a particular RC-buggy
package.
>> We should have an explicit list of such reference installations and
>> declare them as crucial for the release:
> How about:
> all the tasks
> all the blends
That's certainly a good start, although I think it's worth asking the
blends maintainers whether all of the packages they include are
release-critical. I don't think it captures all of the interesting use
cases, though; there are common patterns that we want Debian to support
that aren't captured in a task or a blend.
>> if they work, we can release, and if they don't, we can't.
> How would you define "work"?
> Presumably: no RC bugs, no piuparts issues?
I would limit it to just no RC bugs (and therefore no test failures where
we're pretty sure that test failure would indicate an RC bug). If we feel
that piuparts is testing things that should be RC, that would certainly
include piuparts.
Bear in mind, however, that the core problem is that we don't keep testing
sufficiently free of RC bugs to be able to release in a timely fashion
after a freeze. That means we're not dealing well with the bugs we
already have, so I would be a bit hestitant to create new classes of RC
bugs until we have that situation under control. While looking for new
classes of bugs is something that we should always be open to, I think the
most important step is to try to catch the bugs we were already catching
earlier in the process and to be more aggressive about dealing with them.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: