[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian development and release: always releasable (essay)

Michael Gilbert <mgilbert@debian.org> writes:

> I disagree that there is something fundamentally wrong with how
> development is done.  The primary problems with this cycle were that
> there were something like 400 or 500 extra rc bugs due to a concerted
> effort to report all serious issues found via piuparts, and then the
> existential problem of not enough rc squashers, which in and of itself
> is not all that rewarding.

This is what we say every release, for various values of "piuparts"
(archive-wide rebuilds, license audits, etc.).  And then every release we
have the same problem.  Let's be sure that we're not just trying the same
thing over and over again and expecting different results.

> A certain freeze length is inevitable simply because it takes a certain
> time minimum for people to test and find all of the significant
> compatibility issues with the set of software chosen to be a part of the
> release.  Debian's high quality standard cannot be met with a two-week
> testing period.  Somewhere between 3 and 6 months is much more
> reasonable.

Six months would be an improvement, but I think it's still much too long,
long enough to have negative distortive effects.  I think three months is
a better target to aim for.  (That said, if we could reliably get the
release freeze down to six months, that would certainly be a worthwhile

> There are simply too many rc bugs all the time.  Jessie is already over
> 500 after one week of development:
> http://bugs.debian.org/release-critical

Right.  Which is why we should immediately (for definitions of immediately
that involve the release team taking a much-deserved break, but not for
definitions of immediately that mean "six months from now") freeze testing
again until we're back down under 50-100 RC bugs, whether via fixes and
transitions or whether by kicking out a bunch of packages.  Now is also
the ideal time to kick packages out of testing so that people are aware
that they're in trouble very early in the release cycle.

We always have this surge immediately after the release, but we don't
stomp on it immediately.  We therefore get up to 1000 RC bugs before we
know it, and never get back on top of them without a long and horribly
painful freeze.

> That, I think is the real problem.  How did testing go from a minimal
> (70-ish) rc bug wheezy release to over 500 in one week?  Why didn't
> britney prevent the migration of all those rc-buggy packages?

Because they're not from migrations.  They're from transitions.  They're
all the "this is going to break with a new version of libc6" and the like
bugs that were filed before the release at priority important and were
mass-upgraded after the release.

This is fine and normal, but it means that we should not now be diving
into all new upstream, all the time development immediately.  We should
stop, take a breath, work through these transitions first, get that RC bug
count down to something releasonable again, and then tackle the next thing
that surges RC bug counts.

That's going to require some discipline.  We know from long experience
with the release process that we can use the bully pulpit until we're blue
in the face, but this is a huge project with a lot of developers, many of
whom just don't read mailing lists.  People will keep uploading unless we
put something in place that actually prevents them from doing so, such as
freezing testing migration right now except for pre-arranged transitions
and RC bug fixes.

(It's quite possible that, to implement this properly without drowning the
release team in work, we'll need better tools to manage that sort of
freeze and migration process.)

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: