Re: Temporal Release Strategy
On Fri, Apr 15, 2005 at 04:45:17PM -0400, Patrick Ouellette wrote:
> On Thu, Apr 14, 2005 at 11:59:52PM +0200, Adrian Bunk wrote:
> >
> > On Wed, Apr 13, 2005 at 10:12:31AM -0400, Patrick A. Ouellette wrote:
> > >...
> > > The progression I see is:
> > >
> > > unstable -> testing -> candidate -> stable
> > >
> > > The existing rules for promotion from unstable to testing continue to be
> > > used.
> > >
> > > Promotion from testing to candidate requires meeting the same rules as
> > > promotion from unstable to testing with the following exceptions:
> > > packages must be in testing for at least 3 months, and have no release
> > > critical bugs.
> > >...
> >
> > One big problem testing has are transitions. This includes library
> > transitions, but also other transitions like e.g. an ocaml transition
> > affecting several dozen packages currently waiting to enter testing.
> >
> > Many transitions require a serious amount of manual coordination since
> > all packages have to be ready to go into testing _at the same time_.
> >
> > Please explain how you think any bigger transition can ever enter your
> > "candidate" if you add to the testing criteria a "3 months" criteria all
> > affected packages have to fulfill at the same time?
> >
>
> The system should always be considered a FIFO system. There are only 2
> places packages can enter the system: unstable, and security-updates.
> The coordination of dependent packages will always require manual
> coordination. There is no way around it (unless you completely automate
> the build process so it downloads the upstream tar ball and packages it
> for Debian - and never breaks). The purpose of unstable is to allow
> those problems to be worked out. Once the group of interdependent
> packages is ready (managed to live in unstable for 10 days without a
> release critical bug) then they will all meet the criteria set to be
> promoted to testing. The same thing happens again. Once the entire
> group satisfies the conditions, the entire group migrates to candidate.
> The point of having the promotion conditions is to make sure the system
> is not broken, and can handle library or interdependent package version
> changes. The rules I referred to are found here:
> http://www.debian.org/devel/testing
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".
Please try to understand the limitations of testing before proposing
something even stricter.
> 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: