Re: Suggestion: Skip Slink!
John Goerzen wrote:
>Our problem is that the freeze time is *way* too long. What should be, and
>was designed to be, a few weeks (or a month at the most) has dragged on to
>many months. Its effect is that new software is kept out, while old bugs
>are kept in or not discovered because nobody is running it anymore, and some
>can't even compile for it anymore. People hurridly upload new packages to
>it right before the freeze date, which may cause the release to be
>postponed.
I completely agree. I don't think there's anything we can do about it for
slink though.
I don't think Ben Collins' proposal would do much good either. I think the
freezes are too political and not technical enough. Freeze dates shouldn't be
set in stone, to the extent that our release dates aren't. There are too
many people trying to cheat the system just before a freeze.
The ideal freeze time is about a month. This requires working bootdisks, a
non-broken distribution, no hassles with CD creation, fewer developers on
vacation, and a realistic release-critical bug list (there shouldn't be
*anything* on the list that's really difficult to fix when we freeze).
Any of those conditions remaining unmet can delay release for months.
Yes, I am dreaming. Normal people need the release-critical buglist for
motivation, which is utterly backwards but entirely human.
Maybe the release manager should play a guessing game with us and say
"potato will be frozen sometime this next month when everything looks good"
and then tell us the day after. That'd completely eliminate the
gotta-get-this-in-before-freeze syndrome.
By the way, I thought we weren't going to have any release goals
for slink. Looking through the release-critical bug list I see a few
gotta-fix-this-even-though-it-won't-affect-the-users bugs. If they're on
that list, and they're an important package, they become a release goal
(they hold up the release). We really need to sort through those and pick
which of them will affect users.
>There really isn't much, or anything, to change. There are plenty of people
>that have been running 2.1.x kernels for quite a while with Debian.
There's the kernel itself, pcmcia-cs, kernel headers (which affect an unknown
number of programs), the network initialization scripts (you no longer need
to create a route entry for loopback), ipchains (ipfwadm-wrapper will come
in handy for a lot of people - we need to document this option.), stuff like
that.
Yes, we are mostly there. You can go out and say "Go ahead and run 2.2 on
slink. It likes it." The bootdisks are mostly what I'm talking about
when I say "target".
This means if we freeze potato and 2.2.0 is on pre147 (not too likely :), we
put that on the bootdisks during the potato testing.
--
Robert Woodcock - rcw@debian.org
"Unix and C are the ultimate computer viruses" -- Richard Gabriel
Reply to: