Re: [email@example.com: Re: Woody retrospective and Sarge introspective]
On Tuesday, July 30, 2002, at 10:12 PM, Raphael Hertzog wrote:
Le Tue, Jul 30, 2002 at 04:46:11PM -0400, Joey Hess écrivait:
Because you think that the introduction of testing simplified the work
of maintainers ? Look the pain that it is to follow update-excuses to
see why your package is not entering testing.
Yes exactly -- not imagine the pain of having to track which are in
yet another distribution, and why not.
Well, candidate is not difficult to manage. Either you have uploaded a
package there or you haven't. Since it is not automatically fed it's
easy to know where you are.
To me that's a disadvantage. Personally, I'm likely to forget about
candidate since I'm unlikely to use it. If I have to remember to
explicitly upload packages to it then updates are likely to be erratic
at best. The overwhelming majority of my uploads are things that I
consider ready to release - things like fairly small changes or widely
tested upstream releases - and I see little to be gained over testing
This distribution also have to handle dependencies in some fashion -
even if you do something like allow source only uploads or provide
readily accessible chroots uploading to candidate is always going to run
the risk of breaking things. Look at what happens to testing every once
in a while when a package introduces an undeclared dependency on a
version of debconf that's still in unstable.
I think we're still waiting on it because it does not work on all
Sure, but if it were in unstable, autobuilders (and porters) would have
tried to compile it, they'd have noticed the failure sooner and would
have helped Branden to fix that situation because they don't want to
lag behind i386. Now, only people who are part of the X Strike Force are
I don't know what's actually the case with X, but it's possible for
crippling errors to show up at run time rather than compile time.
"You grabbed my hand and we fell into it, like a daydream - or a fever"