On Fri, Apr 22, 2005 at 02:54:38PM -0400, Patrick Ouellette wrote: > On Fri, Apr 22, 2005 at 07:16:30PM +0200, Adrian Bunk wrote: > > > > The problem is that for many transitions, "slowly" means "never", since > > the criteria you set are unlikely to be fulfilled for all parts of such > > a transition at any time in the future. > > > > And the more time passes, it becomes more and more complicated since > > additional transitions might be interdependent with a transition making > > the problem even more complicated. > > > > You are very good at repeating "this will never work." You are > essentially saying it is impossible for a package to have no RC bugs, > and that those bugs are never going to be fixed fast enough to progress > through the quality control system I proposed. I have a bit more faith > in my fellow Debian Developers than that. > > I admit that the candidate phase will change more slowly than testing - > it is supposed to. The stable (or whatever it is called - maybe > production) section will change even more slowly. This is by design.
Show me how my tiff transition example will work in your proposal, and you can prove me wrong... >... > > > Testing, candidate and stable should change progressively slower. That > > > is the entire point. > > > > > > As I am trying to explain, the speed of changes to stable will sonn > > become zero. > > The speed of changes to stable is currently zero. Debian does not have > to do anything to maintain that. My proposal would at the very least > change that from zero to "glacially slow," with the option to pick a > version that changes "slow", "fast", or "continuously." > > > > > > If you believe your approach would work, please try the following: > > > > Take stable from today, and make this your "candidate". > > Take testing from today. > > > > Actually, I am planning on working on that this weekend. I was not > going to start with the current stable, but with the current testing. I > will be building a candidate list by using my proposed rules (0 RC bugs, > 3 months or more in testing). > > I will build a "new stable" from the candidate list with those packages > that have been in testing 6 or more months with 0 RC bugs. Where do you get the information from how long a package is in testing? Do you have 6 months of update_output, or is there a source I do not know about? > It will be interesting to see how many required, base, standard, and > optional packages meet the standard I propose. >... Since even glibc in testing will not be in your candidate list, I can predict that your result set will be very small since you have to ensure that all dependencies and build dependencies are fulfillable... > Pat cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]