Re: [hertzog@debian.org: Re: Woody retrospective and Sarge introspective]
Le Thu, Aug 01, 2002 at 12:50:45AM +1000, Anthony Towns écrivait:
> If they don't have a good reason to do it, they won't. If "testing+t-p-u"
> doesn't serve their needs better than "testing" _and_ "unstable",
> they won't use it. And it won't -- it has all the problems of unstable
> (untested uploads, dependency issues), and all the problems of testing
> (out of date software).
It's not so evident: t-p-u has packages that maintainers believe to be
ready, so it should be better than unstable wrt quality. Furthermore
it contains newer packages than testing.
It certainly has some merits of its own. And it will find its audience.
> Or, that's what I'd do, it's what most people I know would do, and it seems
> perfectly sensible and reasonable.
Yes.
> Yes, and the new lib doesn't get into testing until all the packages that
> used the old one have been rebuilt with the new one on all architectures.
Ok, why do you impose that ?
I can imagine that you run into problems if you want to keep only one
version of the source package in "testing" (beause the GPL requires us to keep
a copy of the source for each binary package we have) but if you allow
several versions of the same source package, then there's a possibility
to do like I described.
If that change is totally irrealistic, then I might have a second
fallback solution: what about running the testing scripts on unstable
and t-p-u at the same time ? It wouldn't satisfy all my complaints, but
it would eliminate the problem of packages blocked in unstable. But that
would already be better than the current situation.
> Understand the problem first, then try to find a solution that changes
> the _least_ things.
I'm trying. Thanks to your constructive answers and those from Richard
Braakman...
> then got ruminated on some more, and that then had a year's worth of
> hacking before hitting ftp.debian.org, and another year or so before it
> actually started functioning effectively.
Sure :-) That's what I'm doing here, I explain my basic idea, people
tell me what is wrong, I try to find a better solution, and so on.
I don't want to impose any pre-hashed solution -- I don't have any.
I have just *ideas* and I need your feedback to make it evolve in
something that actually has a chance to happen and to make life easier
for the maintainers.
> That's not entirely precise. The maintainer gets to say "This version
> isn't fit to be released", she doesn't get to say "This version *is*
> fit for release". She can't say the latter, because until it's been
> uploaded, until it's been built on other architectures, until the effects
> on other packages have been seen, until people have tried it, she just
> doesn't know.
That's why I explained that the package are supposed to "mature" in
unstable before the maintainer has a chance to be confident about the
status of her packages.
> Trying to base this on "where the maintainer uploads" is wrong on two
> counts: first it requires the maintainer have knowledge that just isn't
> available to her, and second it makes it harder to maintain any individual
> package in the archive.
I don't understand what you exactly mean. What is the knowledge that is
not availabe to her ?
> If you want to change that, you have to be very careful that you _keep_ it
> feasible and maintainable while you work towards whatever you want.
This is possible if I keep getting good feedback. Thanks !
Cheers,
--
Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/
Formation Linux et logiciel libre : http://www.logidee.com
Reply to: