User-Centered Release Goal Proposal for woody+1
With package pools and the testing distribution, the mechanics of the
freeze and release process have gotten much easier. So we now have
the infrastructure to put out releases more quickly. But if we set
ambitious technical goals that require major amounts of coordinated
work on many packages, then the release process itself isn't the
bottleneck so all this great infrastructure has limited effect.
People are considering a lot of fancy goals for woody+1, like
internationalization, policy changes, mods to the way /etc/init.d/
works, autobuild-related improvements, tags, GCC 3.1 on all archs, and
on and on.
These are all laudable goals. But they would each take quite a while.
I propose instead the following release goals for woody+1.
- new versions that didn't make it into woody
- new packages that didn't make it into woody
- bug fixes that didn't make it into woody
- bug fixes for bugs in woody
In other words, a "point release". With no show stoppers. No major
changes to the boot floppies. No drastic restructuring.
Given our release process, if we wait a month or two after woody rolls
out and then start the next freeze, we'll have a release out maybe
five or six months post-woody, realistically. (Remember, with the
gradual freeze it takes a while from the start of the freeze until the
application packages freeze, so those would have more time.)
And it would be a great release, because the lack of internal
restructuring and the rapid turnaround will make the freeze process
itself go more quickly and smoothly. So the release will be fresher,
and our users better served. And the upgrade users do from woody to
woody+1 will be easier for them. And as a project we will take pride
in a release which isn't so far behind upstream versions, and will
gain confidence in our ability to release more often.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: