Re: [email@example.com: Re: Woody retrospective and Sarge introspective]
Raphael Hertzog <firstname.lastname@example.org> wrote:
>> 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.
> 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".
Imvho (but I am no DD) this not doable because it would bind too many
- BTS needs to really no how to associate bugs with versions. (I know,
we want this any way, but "candidate" _requires it.)
- Somebody to take care of it
- Time and effort from the package maintainers: They'd have to take
care and track another distribution, temporarily inresponsive
maintainers might break "candidate" even more than "testing",
because no automatism is involved.
> 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".
If people don't use "testing", "testing" won't be tested enough. OTOH
candidate might break because of the untested packages ("But he can
also make direct uploads to "candidate"").
> 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...
Why should he? Any effort he spends on 4.1 now'll be wasted, because
it won't be included in any stable release, and takes time from him
perfecting 4.2. The X strike force homepage as location of unofficial
testing debs works.
To UNSUBSCRIBE, email to email@example.com
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org