Re: Temporal Release Strategy
On Fri, Apr 22, 2005 at 12:21:49PM -0400, Patrick Ouellette wrote:
> On Wed, Apr 20, 2005 at 04:56:32AM +0200, Adrian Bunk wrote:
> > The rules and goals of testing are clear.
> >
> > The more interesting points are the problems of testing that several
> > years of using it have shown.
> >
> > > If package FOO has a RC bug, then everything that depends on FOO will be
> > > stuck AT WHATEVER POINT IT IS IN THE PROCESS until FOO is fixed. If
> > > fixing FOO breaks BAR, then they all wait again until BAR is fixed. Use
> > > of experimental to work through some of these issues would help.
> > > I'm not saying it won't take manual coordination to handle complex
> > > changes to the system. I'm not saying it will make anyone's life
> > > easier. What my proposal will do is provide the ability to decide when
> > > package $PACKAGE makes it into stable, we will call that an official
> > > release and give it a number. Alternatively, you could declare every
> > > $INTERVAL Debian releases. What is in stable should have been well
> > > tested, and supportable. Stable no longer is a static concept, but a
> > > slowly evolving thing. If you cannot wrap your mind around to accepting
> > > a stable that evolves, we could snapshot stable at release data and make
> > > a separate archive (really a Packages.gz and related files as long as
> > > the version of the package in the release exists in the package pool).
> >
> > You completely miss my point:
> >
> > There are several transitions every month, and a big transition can
> > involve several hundred packets.
> >
> > Your proposal requires, that _every single_ package that is part of a
> > transition has to be both ready and in testing for over 3 months before
> > it can enter your proposed "candidate".
> >
> > If _one_ of the packages that is part of a transition is updated in
> > testing during this time, the 3 months start again. For bigger
> > transitions, it's therefore practically impossible that they will be
> > able to enter your "candidate".
>
> I don't believe I missed your point, you just don't seem to be able to
> grasp the fact that I intend candidate to change slowly.
>
> Yes, I am proposing that every package involved in a transition be of
> adequate quality to be promoted to candidate. The purpose of the entire
> release system is to ensure the quality of the Debian distribution.
> Debian releases "when it's ready" because Debian demands a certain
> minimum level of quality (currently defined as an arbitrary number of RC
> bugs in packages of variable importance in the distribution as seen by
> the release manager). I'm proposing a system that allows "when it's
> ready" to be defined and automated. Our current release system places
> an enormous burden on the release manager.
>
> >
> > Please try to understand the limitations of testing before proposing
> > something even stricter.
> >
>
> I understand the limitations of testing. In fact, I am depending on the
> limitations of the testing rules to ensure that candidate is of adequate
> quality and changes slowly enough to be used on desktop workstations and
> that stable is adequate for servers.
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.
> 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.
> 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.
If you believe your approach would work, please try the following:
Take stable from today, and make this your "candidate".
Take testing from today.
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 approch 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.
> 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
Reply to: