It's not the catchiest subject line, but it'll do.
Short summary: It's about time we froze. Go help Adam with boot-floppies.
The long story is something like this:
I was originally hoping to get woody out by Wednesday, if for no other
reason than for the beautiful double entendres it'd inspire. But for one
reason and another (and another and another and another), it wasn't to
be. We are, though, more or less to freeze now, I think.
As is my wont, we'll take a quick digression already.
I'm sure everyone reading this has different things they'd like to get
out of the next release of Debian. It's probably reasonably appropriate
for me to give a brief idea of what I'd like to get out of it. Obviously,
you're welcome to agree with these or not.
First, I'd like the release process to be a bit smoother than in the
past. Our release process has a few problems: we tend to have no idea
when it's going to end, or where it's going; we tend to not make as much
use of people who're willing to do beta-testing as we might; and we tend
to end up with ridiculously old versions of most of our packages when
we're finally done.
Second, I'd like to have less buggy packages. Personally, I'm embarrassed
to give someone a potato CD, and watch bugs appear doing a standard
install, which could and should've been noticed and fixed with just a
minimum of testing.
Third, I'd really like to see Debian include some of the nice "desktopy"
stuff that's coming out for Linux these days: office software, DVD
players, games, KDE, Gnome, Mozilla and so on. I'd like to see the
installer cope nicely with the hardware that goes with it, video cards and
sound cards and TV cards and whatever. Much of this is already packaged,
but much of it's somewhat out of date, or buggy, or not integrated as
well as it could be or whatever. I'd like to be able to install a Debian
system on some random name brand computer and be able to give it to my
parents or my cousin and have it be fairly usable; maybe with Wine or
VMWare or plex86 on it for any specific Windows programs they need.
There are probably a hundred other goals people have that they'll work
towards for woody, but *my* ideal release would meet those three. The
actual woody release may well not, but, hey, I can hope. How I'd like to
run the whole freeze thing is probably somewhat influenced by the above.
Now, I've screwed up a bit here, because I haven't taken the time to
properly discuss how we're going to do the freeze.
First, and probably most noticably, since we've already got separate
testing and unstable suites, I don't think we'll need to fork a frozen
branch as well. So testers will just need to point at testing/woody,
and uploads will just continue targeting unstable. For those people who
want to do some heavy development on their package that they don't want to
go into woody (or to get in the way of bugfixes for woody), I'm inclined
to think they should probably upload to experimental, or use their home
directory on klecker.debian.org. This should make things a bit easier
for the autobuilders, which tend to have some difficulties coping with
"frozen unstable" uploads.
Additionally, and more importantly, I think we need a little more
structure to our testing than just `Here's 6000 packages, whaddaya
think?'.
So, what I've been thinking, and what I'm (belatedly) proposing, is to
roughly invert the test cycles and the freeze itself, so that instead of
freezing everything then doing test cycles to work out where we're at,
we instead choose some part of Debian to test, test it, and, if it's
good enough, freeze it. Once everything's successfully tested and frozen,
we release.
The three main test cycles I think we'll need are as follows:
1. The base system
2. Boot-floppies, standard packages and tasks
3. Optional and extra packages
Hopefully, this would allow us to have fairly current versions of most
of our packages (ie, optional packages), and also gives us plenty of
time to at least document any known bugs in our base system.
We won't begin any of these cycles until we have basically functional
packages for that portion of the system: so for example test cycle
one won't begin until we've fixed the RC bugs in required and important
packages (and determined what packages are in woody base), test cycle two
won't begin until we've got working boot-floppies for all architectures,
and any optional or extra packages that are uninstallable or have RC
bugs will be removed before test cycle three begins.
During each cycle, updated packages will be acceptable, but major
reorganisations (like X4, the new perl packages, split packages, etc)
and new packages won't be. Note that "new" will probably be compared
to whether it's in testing or not, not whether it was uploaded to
unstable the night before the cycle begins; so it's probably best to
make sure packages are recompiled against new and renamed libraries and
so forth earlier rather than later, which is probably a a good thing
anyway. Otherwise, packages will continue to go in according to the rules
of testing: ie, their dependencies are okay, they don't have RC bugs,
etc. This does mean that packages uploaded a week before the end of the
cycle that are only low urgency won't go in either (unless the cycle's
repeated), since they won't have had the requisite ten days of testing
in unstable before the cycle ends.
At the end of each cycle, we'll either say "Yup, all those packages are
done, they're ready for release right now" and move on, or "Hmm, we'd
really be better off working on this some more", and repeat the cycle.
Hopefully we won't need to repeat any of the cycles more than a couple
of times. If we have month long cycles (which seems about reasonable)
and repeat all the cycles twice, we'll have a "freeze" that lasts about
as long as the potato freeze did.
Note that this will be a fairly hard freeze: once a package gets frozen,
changes will stop being automatically accepted by the testing scripts
(duh), and won't be manually accepted unless it's a release critical
issue and the changes have been carefully reviewed by at least a couple
of people, and everyone's confident nothing'll get broken because of
the changes. If the bug *has* to be fixed, but we can't do it in a way
that we can be absolutely sure won't break things, we'll probably need
to reset the testing cycles right back to the start to make sure things
haven't become royally screwed.
Or at least, that's what I say now (and what seems good policy as far as
QA goes). We'll see what actually ends up happening.
So, a theoretical (and overly optimistic) timeline:
2001.02.15 - 2001.02.28
i386 boot-floppies updated for woody (and any other
architectures)
mips, hppa, ia64 get their architectures in sync and
work on boot-floppies, and work out if they're going to
release with woody or not
2001.03.01
debian-cd folks preduce a "preview release" for i386,
and any other architectures that have vaguely functional
boot-floppies
2001.03.01 - 2001.03.31
policy gets finalised (/usr/share/doc? task-* packages?
invoke-rc.d? crypto and non-US?)
people work on porting boot-floppies to all architectures
that plan on releasing
any major new updates to base packages that'll be included
in woody get added to woody (apt 0.4, perl 5.6 reorg)
any RC bugs in base packages get fixed (binutils/m68k,
ncurses/sparc, ...)
2001.04.01
the architectures that'll release with woody have working
base systems (and probably passable boot-floppies)
2001.04.01 - 2001.04.30
base packages testing cycle; QA and testing focus on
finding and fixing any irritating bugs that can be
fixed in those packages without having to rewrite them
from scratch
boot-floppies become usable, and basically feature
complete for all released architectures
RC bugs in standard and task related packages fixed
2001.05.01
base packages finalised: security updates only
boot-floppies are basically feature complete
no new standard packages, no new tasks, no changes to
what're in tasks
2001.05.01 - 2001.05.31
standard installs finalised, boot-floppies bugs fixed, etc
RC bugs in optional/extra packages fixed (for those packages
that want to release)
2001.06.01
no more RC bugs in any packages
first CD complete, and won't change except for security
updates
standard installs (ie, ones that use tasks to choose
what packages to install rather than dropping into
dselect/console-apt) are complete, and won't change either
2001.06.01 - 2001.06.30
final testing of optional/extra packages
finalisation of release notes, press releases etc
2001.07.01 - 2001.07.07
final security updates before release
CDs built
2001.07.08
release
Now, those dates are obviously not realistic: it's questionable whether
there'll even be alpha-quality i386 boot-floppies by the end of this
month; and some of the test cycles will probably be delayed because RC
bugs won't be fixed; and some may need to be repeated, or reverted.
Let me note that again for anyone from the press that might be reading:
<blink>
THOSE DATES ARE NOT REALISTIC!
</blink> [0]
As far as risks go; the biggest ones seem likely to be fixing weird
toolchain issues (getting Qt to build on alpha, binutils on m68k,
ncurses on sparc...), and getting from more or less nothing to working
boot-floppies. For reference, it took about six months (Nov '99 - Jun
'00) to get boot-floppies for potato, the above timeline only budgets
three or four for the same job. So go help Adam on boot-floppies.
So now's probably a good time to orphan those packages you haven't been
maintaining for a while, or to update those packages that've had new
upstream versions for a year, or to send in patches for those bugs
that've gone unfixed for months, or to do that reorganisation you've
been leaving 'til the last minute.
From about this point until we've released, it's probably reasonable for
people to NMU packages with release-critical bugs without overly much
notification. Hopefully we'll have some Bugsquash weekends organised
soonish as far as that goes.
In all the above, I've blithely assumed that there are a bunch of
non-developers who're helping out doing test installs and upgrades
from potato and reporting bugs and generally helping out with QA. This
usually takes place on the debian-testing mailing list, and in the
past there's been someone organising that (producing "install report"
forms, and helping out people who haven't used the bug tracking system
before report useful bugs, and so forth). I don't think we've got anyone
available to do that yet this time around, and we probably need someone.
Volunteers might like to work on getting something organised on the
-testing list.
We also probably need some documentation people. At the very least, we
need someone (ideally someone*s*) to write and collate release notes. [1].
Volunteers probably should join the debian-doc list and the debian-boot
list and work out how to hack on the release documentation.
So, hopefully that doesn't raise too many more questions than it answers.
In the next few weeks, the most important things to do is make sure
your (and others') packages are basically how you want them to look
when they're released. So, file bugs, ask for help, work on patches,
upload fixes, and work on boot-floppies.
Have I mentioned you should help out with boot-floppies?
Cheers,
aj
[0] Not that I'm trying to imply that all members of the press would be
low-brow enough to have mail readers that use HTML. Heaven forbid.
Would you like to hear about Debian's Secret Plan to Fight Inflation?
[1] It'd probably also be nice if someone'd write a testing/freeze
FAQ too, since there're probably going to be a fair few (as though
there aren't already). Hopefully we won't have to do much reinventing
next release, so it should last a little while at least. Ideally
someone other than me should write it, since I've been working
on testing and thinking about how a release should go for a year,
so I've forgotten half the assumptions I've made and so on...
-- Anthony Towns <ajt@debian.org> Woody Release Manager
-- To UNSUBSCRIBE, email to debian-devel-announce-request@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
This archive was generated by hypermail 2b30 : Fri Feb 16 2001 - 11:38:38 CET