Manoj Srivastava <[EMAIL PROTECTED]> writes: >> 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.
I thought freezing testing was planned. That's the incremental freeze which is confusing. >>> 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. Again, I thought it was planned by RMs. > 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. I fail to see how I can prove anything 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. It depends of the criteria of equality. You don't necessarily want to be that strict. -- Jérôme Marant http://marant.org