Re: Temporal Release Strategy
On Wed, Apr 13, 2005 at 11:11:13AM -0500, Gunnar Wolf wrote:
> Date: Wed, 13 Apr 2005 11:11:13 -0500
> From: Gunnar Wolf <gwolf@gwolf.org>
> Subject: Re: Temporal Release Strategy
> To: "Patrick A. Ouellette" <pat@murphy.debian.org>,
> debian-devel@lists.debian.org
>
> Patrick A. Ouellette dijo [Wed, Apr 13, 2005 at 10:12:31AM -0400]:
> > (...)
> > 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.
> >
> > Promotion from candidate to stable would follow a similar pattern, with
> > a time in candidate requirement of 3 additional months.
>
> Umh... There is a simple problem with your proposal: Most of my
> packages are quite stable, yes, but some would never reach candidate
> status. Try uploading a package every five days (with priority=low) -
> it will never reach testing, as the old version disappears under the
> new one.
If you upload a package to unstable every 5 days with a low priority it
will not migrate from unstable under the current system without manual
intervention.
>
> Yes, this could be sorted out, so that old versions no longer
> disappear until ${fateful_event}. This would create more problems: If
> a RC bug report is closed, you will have to keep track of which upload
> did the trick, not considering any of the ones below it for testing or
> candidate.
The only time you need to worry about old versions is in the final
stable tree. If a package in stable depends on another package with a
== or <= version dependency, the promotion of the new package would
break stable. This means one of two things needs to happen: either the
old package needs to be upgraded or the old package needs to be removed.
Policy would have to be set on what the proper action is for orphaned
packages. I don't think it too unreasonable to expect an actively
maintained package to be updated within 9 months of the upload of an
updated dependency. I don't think it too unreasonable to remove an
orphaned package that reaches that state either. People have complained
about the number of packages - now we have a natural method to remove
packages from the distribution that are no longer used.
A package must be in unstable for at least 2 days according to the
"rules" in the FAQ. The preferred time is 10 days. Uploading every 5
days with low priority should just replace the package with the newer
version and start the clock again. If your package is unable to meet
the 3 months time in testing (or the 10 day time in unstable) due to
frequent uploads, then it really is not a stable package - is it.
That is the point of having a "stable" branch - it should change slowly
and the packages in the stable area should be, well, stable.
If an RC bug report is closed, the new package is uploaded to unstable
and must run through the process. The idea being that by the time your
package reaches candidate or stable status it really is stable and
contains no known RC bugs.
>
> Finally, this would make any library migration a real nightmare :-/
> You'd have to somehow keep the archive synchronized, doing something
> similar to what is currently done re:testing, but on a _much_ broader
> scale. Tracking dependencies and FTBFS bugs could become basically
> impossible.
The rules for migration from unstable to testing cover the library
migration issue. If a package has a depends on one or more other
packages, all must exist and be satisfied for migration to occur. So we
either already have this problem, or we don't. If we have the problem,
we need to solve it anyway....
>
> ...But if you come up with an implementation, I'll just shut up :)
>
Discussion first. Then consensus, then implementation.
Pat
--
Patrick Ouellette
pat@flying-gecko.net
kb8pym@arrl.net
Amateur Radio: KB8PYM
Reply to: