Re: Debian development and release: always releasable (essay)
On Thu, May 9, 2013 at 3:49 PM, Lars Wirzenius wrote:
> The wheezy freeze has been much too long. At ten months, it's four
> months longer than what we've gotten used to in several previous
> releases. Had we managed to keep the freeze at six months, it would
> still have been too long. I believe there is something wrong in how
> we develop Debian, and how we do releases, and that by fixing them,
> we can have much shorter releases, with an increase in their quality.
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. You address the former with the more
automated testing comment below. The latter could possibly be
addressed by bring in more DDs, and that means doing better with
-mentors.
Anyway, those are the two problems that I believe need focus.
> We should aim for a short freeze, perhaps as short as two weeks,
> and certainly not longer than two months. This would remove the
> frustration, and fix the other problems related to a long freeze.
> However, to achieve a short freeze, we need to change how develop
> Debian.
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.
> The fundamental change is to start keeping our "testing" branch
> as close to releasable as possible, at all times. For individual
> projects, this corresponds to keeping the master or trunk branch
> in version control ready to be released. Practitioners of agile
> development models, for example, do this quite successfully, by
> applying continuous integration, automatic testing, and by having
> a development culture that if there's a severe bug in master,
> fixing that gets highest priority.
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
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?
> Imagine a continuous integration system for Debian: for every new
> package upload to unstable, it builds and tests all the reference
> installations. If all builds succeed, and all tests pass, the package
> can be moved into testing at once. When you, a developer, upload a
> new package, you get notified about test results, and testing migration,
> within minutes.
I am in total agreement. This would be wonderful.
Best wishes,
Mike
Reply to: