On Sat, 23 Oct 2004 01:04:41 +0200, Jérôme Marant <[EMAIL PROTECTED]> said:
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>>> What do you think we'd get by combining both (testing + unstable
>>> freeze)?
>>
>> If you freeze unstable anyway, you are blocking the updates -- and
>> thus have all the problems of this style of interrupted
>> development. If unstable is frozen, what is the point of Testing?
> Testing scripts are a gatekeeper against mistakes from unstable.
> Upload debian-specific changes to unstable doesn't necessarily mean
> there won't be side effects that shall not enter testing.
Why not just leave freeze testing, and create an
ultra-pending-release frozen candidate branch which is a gatekeeper
against mistakes from testing. Freeze testing instead.
>> Am I missing something in your (somewhat nebulous) proposal?
> Freezing unstable prevent people from uploading new upstream
> releases which desynchronizes unstable from testing and forces
> people to work with two distributions (and necessarily neglect one
> of them).
How does this actually make testing become releaseable sooner,
if testing is actually frozen? freeze testing, leave unstable alone,
and create as many harder-frozen-ready-to-release candidate variants
of testing you want.
See, you don't really need people in power to do this: just
create a fake-testing somewhere, and a fake-frozen, and see if things
actually come together sooner that way.
> As soon as testing is strictly equal to unstable regarding package
> versions, testing is roughly ready for release.
This may take forever. However, frozen-testing and
frozen-candidate may fugue towards equivalence asymptotically.
manoj
--
You will have many recoverable tape errors.
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
