Re: Woody retrospective and Sarge introspective
Le Wed, Jul 31, 2002 at 03:49:17PM +0300, Richard Braakman écrivait:
> Hmm, maybe I should expand on that. I don't think that we have
> enough experience with the "testing" system to consider replacing
> it yet. We have done one release with it, and we've found a few
> problems that need fixing (such as testing being the least secure
> distribution), but I think it's simply too early to call for
> another major redesign of the release system. A new system will
> have its own "birth problems". Let's see how the sarge release
> goes, now that we have the "testing" system in place.
I'm tempted to agree, my initial proposition pushed "testing" on the
side, it was not a good move.
However we already have some experience about testing and we identified
real problems :
1) keeping a package out of testing can be done by filing RC bugs, but
this causes problems for other packages who will not be able to move
to testing because they depend on it.
Ex: libA 2 is in unstabl
libA is voluntarily kept out of testing with a RC bug
progB is in unstable and depends on libA 2 because it is compiled
against it
progB will never enter testing before libA enters testing even
if it can compile and work with libA version 1 that is in testing
=> this can be worked around with testing-proposed-updates if we add an
automatic promotion from t-p-u to testing
2) packages from unstable are not always ready to be included in
the "next stable release". I'm not sure that relying only
the testing scripts is enough. I wanted to add an explicit
action from the maintainer to make sure that only good packages are
sent to it.
Actually the logic is "if a package is not ready, file a bug to keep
it out". I want to reverse the logic, keep it out by default, and
only send it when the maintainer knows it's ok to use it.
> To summarize, I think you're saying that packages need to have been
> tested for several months before they're releasable, and the ones in
> testing are too young. Is this right? Do you mean most packages,
> or only a few packages?
Yes, that's right. I don't think it applies for most packages but a
significant proportion. And the real problem is that in those packages
you have a certain number of "core" packages on which many other
packages will depend. So blocking them in unstable will annoy many
people. And having them in testing too soon will result in testing
being unreleasable until they stabilize.
> I expect that getting large updates into "candidate" will be even more
> difficult than getting them into "testing", if the uploads are manual.
Yeah, forget about candidate as an "isolated" distribution. Read the
last proposition in debian-devel :
* upload packages ready for release to t-p-u (they are built against
testing)
* use the testing scripts to promote packages from t-p-u to testing
* keep unstable as an isolated dist where we "mature" packages
> If this is your major concern, then I think it's easily tweaked: have
> a way for developers to mark packages as "don't auto-promote to testing".
> This already exists, via the BTS. A more direct interface might be nice
And it has big drawbacks, see before.
> (An exception might be for packages that by nature
> should never be promoted, such as -cvs versions. Having a permanent
> RC bug open on them is annoying.)
For this, we might consider putting them in experimental since they are
not meant to be distributed in a stable release.
> If you mean that the default should be reversed, then it could be done
> with a change to the testing scripts: have them mail the maintainer
> when a package is ready for promotion, and wait for confirmation.
Yes, it would be better, but this solution has the same disadvantages of
blocking packages that depend on your package in unstable.
Cheers,
--
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Formation Linux et logiciel libre : http://www.logidee.com
Reply to: