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]
