Re: Temporal Release Strategy
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.
>
> > I am proposing a system that removes some of the arbitrary nature of
> > what we call a stable package. I'm proposing that we define QUALITY
> > CONTROL standards that ALL packages adhere to so that when someone says
> > they recommend Debian's testing/candidate/stable release, they can point to a
> > testing system that allows the person to select which branch they use
> > based upon well know published criteria for the stability of that
> > particular branch. The user controls the amount of risk they are
> > willing to have in their system.
>
>
> That's already true today.
>
> People who like the latest software can choose between unstable and
> testing with testing usually having a bit less known bugs.
>
> People who want stability use stable.
>
It is not true today. What is true is people who are not running
hardware less than 36 (or so) months old have the option of running
stable (the kernel shipping and included with stable just does not have
drivers for new hardware). This has been a perpetual problem.
People who need a stable distribution should not be forced to use
testing or unstable because they have hardware that is only 18 months
old, especially when you consider the pace of change in computer
hardware manufacturing.
The reality today is people who have older hardware can choose to run
Debian stable. People with newer but by no means cutting edge hardware
do not have the option of installing stable. They can choose testing or
unstable.
People who want security updates from the Debian security team must run
stable. If you want security fixes and have newer hardware, you must
run unstable (and hope the maintainer uploads a fixed version quickly)
or patch the testing packages yourself.
People are not able to choose by their desired "comfort level" of
stability. If anything, my proposal might allow people to choose which
version they want to run based on their desired level of stability -
instead of what will run on their hardware.
>
> > 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.
It will be interesting to see how many required, base, standard, and
optional packages meet the standard I propose.
> Create a complete list of all packages that have to go from testing into
> your "candidate" _at the same time_ for getting e.g. the tiff transition
> into your "candidate".
>
> If after this you do still believe your approach would work, please send
> the complete list of packages you think would be involved in this one
> transition (to let me check whether you missed some - they are much more
> than hundred), and explain at which time of the future you expect
> every single package in the list to fulfill your criteria at the same
> time.
>
I will publish the results on my people.Debian.org page at
http://people.debian.org/~pouelle/temporal_release.html
Look for that URL to be updated by 13:00 25-APR-2005 UTC
I will not be able to explain at which time I expect a particular
package to meet the standards since I don't maintain each and every
package in Debian. Debian always releases "when it's ready" and I don't
expect that to change.
Pat
--
Patrick Ouellette
pat@flying-gecko.net
kb8pym@arrl.net
Amateur Radio: KB8PYM
Reply to: