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
> 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...
"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