Release management
Some issues of release management are being discussed again, so I thought
I'd speak up and give my views.
What I would like to see is two releases per year, with a freeze time
of about one month each. This gives five months per release for
development, of which perhaps one month will be spent on pre-freeze
issues.
What we have right now is releases that take about a year, with half
of that time spent in freeze. By the time we make a release, it is
almost outdated already.
For potato, I'd be happy enough if we get a shorter freeze, even if
the total release time is not reduced. Once the freeze process is
under control, it should be easy to get faster releases.
The main reason right now for not freezing is the large and rising
number of release-critical bugs. We're over 200 already, and the
number is going up rather than down. The boot-floppies also need
work.
I have two plans for dealing with the release-critical bugs.
The first is to contact each maintainer of such a package, and ask
what's up, and collect these reactions in the weekly report. This
approach has helped before, with the hamm release. Josip Rodin has
volunteered to do this :)
The second is to go ahead and mark a number of packages as "will be
removed" if their bugs are not fixed before the freeze, and then
arrange for the weekly report to not count them, and list them in
a separate section. These are the packages that would have been
removed from frozen now, if we'd had an old-style freeze. This will
let us concentrate on bugs that will actually slow down the release
process. (Nothing stops you from rescuing a package by fixing its
bugs, of course.)
Richard Braakman
Reply to: