On Mon, 12 Apr 2004 18:04:33 -0400
"Derrick 'dman' Hudson" <dman@dman13.dyndns.org> wrote:
>
> How about shortening the release cycle so that "stable" is more
> up-to-date? Let's solve the problem rather than the symptons. :-).
>
> (Note - this is not an invitation to begin a flamefest regarding why
> the release cycle is so long or to make suggestions regarding what
> other people can do to fix it. Instead it is an invitation to first
> recognize the issue and second to help resolve it)
One thing that I've never understood, and haven't figured out by
reading the Debian Reference or by osmosis from posts here (probably
the Debian Developer documents is where I *should* look) is how the
"goals" for a release are determined and communicated to anyone
interested.
What I mean by "goals" can be illustrated by an absurd example.
Imagine that the day after sarge becomes stable, the testing
distribution is still exactly the same as sarge, except for a
revision update of some non-essential package (e.g. liferea or
frozen-bubble); that's all that's come down to testing. This would
be a distro that could be released as stable; but it wouldn't be,
of course, because why issue another stable release when the only
difference is a slight change in some non-essential package? I
know Debian's main threshhold for release is "when it's ready";
but the new release has to be sufficiantly different from the
immediately previous one.
So I would guess that there's some set of target properties that
testing should have before it gets frozen that gets decided upon,
e.g. "the next release must include a 2.4 kernel by default with a
2.6 kernel optional, the new installer, XF86 v4.3, exim4, GNOME 2.2
or higher, etc." Whatever else is true about testing, and even if
the release-critical bug count is zero, the release won't be made
until these changes in the distro have been effected, since otherwise
it isn't different enough or interesting enough to put out there as a
new stable release. And I wonder how those goals are chosen, and
where one goes to find out what they are. Probably an archive
search of debian-devel would do it; but a better-publicized source
(e.g. a page on the Debian website) might be a good idea. If the
user community had a clear idea what the major issues for each new
release are, they'd know the particular packages/services to
concentrate on playing with and filing good bug reports about and
so on -- thus perhaps helping to speed up the release.
I know that a major focus of this release is the new installer, and
that right now that's the main thing people should focus on to help
the release get out. But earlier, I dunno what else I should have
been installing and hammering on to help the release along. I could
probably find it in debian-devel's archives; but maybe a page off
the Debian front page ("Minimal Goals for the Next Release") would
be a good idea.
I dunno.
-c
--
Chris Metzler cmetzler@speakeasy.snip-me.net
(remove "snip-me." to email)
"As a child I understood how to give; I have forgotten this grace since I
have become civilized." - Chief Luther Standing Bear
Attachment:
pgprduSTY4hcD.pgp
Description: PGP signature