Re: Woody retrospective and Sarge introspective
On Wed, Jul 31, 2002 at 12:06:27AM +0200, Raphael Hertzog wrote:
> Le Wed, Jul 31, 2002 at 12:18:27AM +0300, Richard Braakman écrivait:
> > You keep saying "unstable/testing".
>
> Yes because they are connected.
There is a barrier between them, however, consisting of technical
measures and policy. Maintainers have an option of blocking the
connection entirely for certain packages, and the release manager
has the option of forcing packages through the connection. Maintainers
can also upload to a proposed-updates directory if something needs
to go directly into testing, with the release manager's approval.
I think that before we consider the massive amount of work that comes
with adding a fourth distribution, we should consider changing the
measures and policy for testing, if the current ones are broken.
(I'm not yet convinced of that last point, mind you. They might need
a bit of tweaking, but things always do.)
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.
> > If it's really true that such large updates go into testing before
> > they're releasable, then that means testing is not living up to its
> > purpose.
>
> What I say is not only applicable to "large updates", it is equally true
> for small independant packages. See my answer to Joey Hess in
> debian-devel (a few minutes ago so I have no url to provide you).
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?
> > In other words, once you add "candidate", what is the purpose of "testing"?
>
> Knowing that a package meets basic quality criteria and that you can
> think about uploading it to "candidate". But that upload must no be
> automatic since entering testing doesn't mean that the package satisfies
> the maintainer wishes...
I expect that getting large updates into "candidate" will be even more
difficult than getting them into "testing", if the uploads are manual.
Consider something like a desktop environment (let's call it kdnome)
that has a major, incompatible release. 400 packages, with 200 different
maintainers, will have to be recompiled before all the dependencies
are right again. The recompiled packages won't work with the old kdnome,
and the old packages won't work with the new kdnome.
How do you propose to get this mess into "candidate", with 200 maintainers
working on their own schedules? (And remember that 50 of them haven't
been seen or heard of for years, and some of them don't have working
keys on the keyring.)
> [...] But that upload must no be
> automatic since entering testing doesn't mean that the package satisfies
> the maintainer wishes...
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
but it's not essential, and personally I like having the information
visible in the BTS. (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.)
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.
Possibly with a default promotion if no yes/no/never/always answer
comes in a minimum amount of time. If "ready for promotion" doesn't
look at dependencies, then this would not be a difficult change.
> [ Of course one could use a fake RC bug for that with testing too.
> But this behaviour completely blocks people who have packages depending on
> the "blocked" ... if their packages are ready they can't send them to
> testing because autobuilders will build against the "blocked" package ]
I don't understand what you mean here. How will "candidate" solve this?
Are you proposing to let maintainers put packages in "candidate" before
their dependencies are fulfilled? Or are you proposing some way to tell
the autobuilders to build against "candidate"? (We could do that for
testing just as easily/difficultly). Where would the packages live in
the meantime? Or would they go into "candidate" before they're compiled
on all architectures?
> > > several large updates like this one which cross in the thime (perl-5.8,
> > > gcc3.[12], xf4.2, kde3, ...), you get many troubles to effectively "freeze"
> > > the distribution ...
> >
> > I don't think so. What happens is that testing lags behind unstable
> > for a while. I expect that a manually-updated distribution will lag
> > even worse.
>
> This is not contradictory with what I said. What you're saying is true.
Hmm, but my point was that "candidate" would not actually help. Either
the updates stay in unstable (in which case testing lags and candidate
lags worse) or the updates are pushed into testing manually, breaking
some dependencies. Since with "candidate" individual maintainers can
do the pushing, I expect more of that kind of breakage there.
--
Richard Braakman
"I sense a disturbance in the force"
"As though millions of voices cried out, and ran apt-get."
(Anthony Towns about the Debian 3.0 release)
Reply to: