Re: [email@example.com: Re: Woody retrospective and Sarge introspective]
Le Wed, Jul 31, 2002 at 11:30:48PM +1000, Anthony Towns écrivait:
> t-p-u isn't a full distribution, and doesn't get any testing. The
> former means the testing scripts can't run on it, the latter means
> they shouldn't.
It's a matter of guidelines.
One day we told our users to use testing, they did. We can as well ask
them to add t-p-u in their sources.lists to test thoses packages ...
The recommended way to test "t-p-u" would be to have t-p-u and testing
in the sources.lists.
> Also ensuring that we can't ever transition to libraries with bumped
I don't see why, it would probably take more time because packages
wouldn't get built against the new lib until the new lib is
available in testing, but I don't see that like a big drawback.
Maybe I'm missing something else ?
> > I'm not able to determine it, I'm just able to see that the version
> > in unstable has gone through 2 new upstream version while testing
> > hasn't. I can inform him that he may want to upload the last well tested
> > package in testing-proposed-updates ...
> No, what you can and should do is help fix the bugs that prevent the
> newer version from being releasable.
One doesn't prevent the other. You always have one day where you have to
say "this version is for stable, this one for unstable". This is usually
imposed by the freeze date ... but it would be as good if it was also the
> testing-proposed-updates is a solution for security updates, and similar
> high importance / low risk changes, low frequence updates. From an archive
> and buildd point-of-view it might be possible to make it something more
> than that, but for a release process point-of-view, it's not. Changing
Now I have something feasible but it's not ok from "the release process
point-of-view". Can you elaborate a bit more please ?
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Formation Linux et logiciel libre : http://www.logidee.com