Re: Future releases of Debian
On Sun, 20 Jul 2003, Adrian Bunk wrote:
> On Sat, Jul 19, 2003 at 10:39:20AM -0500, Drew Scott Daniels wrote:
>
> From a user's point of view it doesn't matter whether the lack of
> security updates is due to technical problems or due to missing man
> power - all that matters is that security updates for testing are
> currently not available.
>
You missed my link. They are currently available through t-p-u, but not
through security.d.o. I seem to remember aj arguing for security.d.o
needing to have a testing queue and Joey arguing against it. There was a
long thread about this recently. Just as it should be in a volunteer
organization, if more people step forward to help, more will likely get
done, i.e. if someone steps forward to help make security updates for
testing I'm sure they won't be shunned, until then no individual is
willing to do all the work. Once I'm a Debian developer I may be willing
to help solve this problem, until then I don't really want the hassle...
even then I'm not sure if the resources would be easy to get in place.
> You talk about your personal "date estimate" and " Sarge will likely
> 'freeze'". The last sentence is in the passive form. Unfortunately, a
> freeze doesn't happen by itself, it's something that must be actively
> done. Besides this, it's also important for maintainers to know early
> enough when the freeze will definitely happen - a freeze short time
> after the latest GNOME beta has entered unstable or a new major release
> of gcc was made the default compiler is quite useless.
>
Colin Watson talked about a freeze state of mind. In the past the first
steps of a freeze involved policy and on which packages should stay in.
With the new testing distribution this step is sort of already happening.
If a new version of package x comes out after a formal freeze then we
already have in place a way of dealing with that. I think it's important
to get things ready for a freeze so it can be as short as possible and all
the packages can be "the latest [stable] package" within the time period
of the freeze. As to your GNOME and gcc an argument... if the beta is that
bad then it shouldn't have gone into unstable let alone sarge. I'll agree
however that sometimes packages that are in a bad enough state do go into
unstable... sometimes for good reason, sometimes not, but at least we have
the RC bug mechanism for making sure that they aren't horrid. Do you have
a better suggetion as to when to tell a package is worthy? I think
anything else would be too limiting, but then I can't say for sure... If
you decide there is a better way, please sit on it for at least a day and
do a nice writeup... it won't likely be received well, but if well
prepaired it may get accepted.
> Your personal prediction is that Debian 3.1 will be released in summer
> 2004. Unfortunately, this doesn't matter much as long as there's noone
> who sets definitely the rough dates. Yes, you can't tell the exact
> release date, but someone has to set the beginning of the freeze early
> enough (see above) or there will never be a beginning of the freeze
> since always new software with new problems floods into unstable.
>
Freeze early and often? Perhaps it would be worth having overlapping
freezes, but one testing distribution seems difficult enough. People whine
if you don't include something like gnome, new Xfree86, kde, gcc... Where
do we make the cuttoff? Well, that's the RM's decision.
> IMHO a Debian 3.1 with an installer that isn't worse than the one in
> Debian 3.0 is the minimum.
>
Mine too although there was much whining about the old installer and
sarge+1 probably won't be out for a while so others may argue to wait.
> If it would take e.g. one year to get $important-nice-feature into the
> installer there's enough time to release Debian 3.1 and start the freeze
> for Debian 3.2 short after the release of Debian 3.1 to get this
> $important-nice-feature into a stable release.
>
I don't think it'd be one year, but it may cut into the freeze if
forgotten and then may delay the freeze. Freezes should be as short as
possible (imho).
> If a freeze date would be set e.g. in two months from now I don't expect
> any unsolvable problems with the software currently in unstable (except
> perhaps the installer). If the time until the freeze is used for a big
> decrease in the number of RC bugs things wouldn't look bad for a
> Debian 3.1 in the first half of 2004. OTOH, I miht be able to fix let's
> say 100 RC bugs, but without a definitely knowledge about release plans
> this doesn't help anything.
>
I assume you mean the software currently in testing, and I do. I also see
many more problems with sofware in unstable. RC bugs could be worried
about in a freeze.
> > If you want to help with the co-ordination of releases and revisions you
> > should subscribe to debian-release and offer your services in places that
> > seem appropriate and useful.
> >...
>
> Looking through the debian-release archives it seems the list is pretty
> dead this year.
>
Not really, just low volume. The last few months have been pretty dead,
but the Assigments were very important. Unfortunatly most of the big
things seem to take place with very little transparency, I've been trying
to fix that.
Overall I have to say I also want releases more often, and I bet most
people do too. I can't say how we can achive this, if you can, please
polish up a proposal and present it. Keep in mind the concept of "release
goals", the way things are currently done, the limited manpower available,
and how we could transition to your proposal (i.e. after sarge is
released?).
I would like to see more security updates for testing. It wouldn't
be an issue if testing is released more frequently...
I'm also pondering a way to create "bleading edge" "Debian" which would
make use of debian/watch files (very buggy, many problems, but possibly
popular and should show the huge value added by maintainers).
I've also been thinking about how to make a version of "Debian" that could
support many individual backports. I haven't presented a proposal on this
as I haven't had time to sit down and think about potential problems and
implementation issues.
Drew Daniels
Reply to: