Re: Woody retrospective and Sarge introspective
Le Sat, Jul 27, 2002 at 04:46:58PM +1000, Anthony Towns écrivait:
> So, I'm going to try breaking my -devel-announce habit. I wonder if this
> means nobody'll notice this mail. I guess I can hope, hey?
Good try :-)
> The main things blocking (1) were:
>
> (a) the six month delay before we started trying to release
> (b) boot-floppies taking twelve months to develop
> (c) CDs not being ready
Speaking as debian-cd maintainer :
debian-cd has always been in pretty good shape if you exclude all the
incantations that have to be done to make CD bootable for some
architectures. I don't have real responsable behind each architecture
to say "heh make it working" ... and mails to
debian-<arch> are not always responded. Furthermore, we never had any
real target timeframe ... and of course, our work is mostly dependent
on the availability of correct boot images provided by boot-floppies/d-i.
If a CD doesn't boot on a given architecture, we can simply
make it non-bootable and provide them for upgrade purpose (that has been
the case for arm and mips since the beginning).
And, sad but true, a threat "if CD doesn't build on X in 2 weeks then
we'll release with a non-bootable CD" usually works ...
Anyway, I think that you shouldn't worry too much about debian-cd.
> My opinion on what we should do about this hasn't changed much: I still
> think the best way of getting consistent, controllable is to maintain
> a candidate distribution in a releasable state permanently.
I completely agree with you. But I don't think that this candidate
distribution should be "testing". It should be a separate distribution
in which explicit uploads are made.
We may not need a complicated setup like the one I proposed in my platform :
http://www.debian.org/vote/2002/platforms/raphael#release1
But we need a similar scheme maybe with only one "candidate" release
without any "testing script" running on it.
So we keep "unstable" and "testing" like they are, but we create a new
"candidate". Testing is a simple way to see if a package can be
considered ready for "candidate" and the maintainer may be able to
move packages from "testing" to "candidate" without any upload.
But he can also make direct uploads to "candidate".
This is really useful for many purposes... let's take the Gnome2
transition. People keep complaining that we're going to impose Gnome2 to
testing users by uploading it to unstable whereas it's not yet perfectly
ready for end users. (we'll try to avoid that by feeling RC bugs on
Gnome2 but hey ... it's not a very clean solution because of all the
other inter-dependencies problem we're going to have)
With a candidate release that would have Gnome1.4 until Gnome2 is
completely ready, we don't have that problem, we just have to explain
to people that they should use "candidate" and not "testing".
In the same way, XFree86 4.2 could go in unstable and we can keep
XFree4.1 in candidate and Branden can continue to maintainer
XF 4.1 if he wishes...
> can be kept to a minimum. Anyway, I'd like to continue bossin' y'all
Yeah ! As long as you still have some time for other
non-RM tasks ... ;-)
> "roughly" releasable status ASAP then keep it there. By that I mean
> getting some official CDs made for testing quickly, and automating them
> so they get updated every week or so. I mean getting some installers for
> sarge into the archive and maintained across all architectures as sarge
> develops. Likewise for security updates. And, in general, likewise for
> anything else that's important to have working when we release.
Agreed.
You also said, that freezing "base" has been difficult because packages
took much time to be corrected, I really think that all "base" packages
should have several maintainers... we can't enforce it, but we have to
promote that idea (using the PTS, using Uploaders: field, ...) and
follow some stats to see if we manage to improve the situation.
Cheers,
--
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Formation Linux et logiciel libre : http://www.logidee.com
--
To UNSUBSCRIBE, email to debian-project-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: