[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Temporal Release Strategy

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



       "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

Reply to: