Re: Temporal Release Strategy
On Mon, Apr 18, 2005 at 07:37:40PM -0500, Gunnar Wolf wrote:
> Patrick Ouellette dijo [Sat, Apr 16, 2005 at 01:04:59AM -0400]:
> > (...)
> > Another difference is that testing will get new versions of packages and
> > those versions might (but should not) cause breakage. Testing has had
> > breakage issues in the past. Ten days is not enough time to catch all
> > the possible interactions (or even the majority of them). I'm also not
> > naive enough to think that my proposed "candidate" step will never cause
> > breakage. The purpose of the additional step is to have a place where
> > things change slower than testing to catch more of the obscure bugs that
> > only become apparent with more time. By requiring there be 0 RC bugs to
> > progress from "testing" to "candidate" and "candidate" to "stable" we
> > cause stable to change when the software really stabalizes, not at an
> > arbitrary time selected by the release team.
>
> Umh... And... Well, if a RC bug is found in candidate, will it take (a
> very minimum of) one month for the fix to get there?
Yes, that is true. It will take time for the fix to work through the
system, and there is also the possibility of finding additional RC bugs
in the candidate version that further delay the cycle. That's how the
iterative develop-test-release cycle works.
>
> Don't you think that, during the release cycle (and specially during
> its first phase after a release) we will always have one RC bug
> keeping a second one from getting fixed?
>
If that is indeed the case, no software would ever be released.
The trick is to make the number of known RC bugs at the time a package
moves from one stage to the next 0. If a bug truly is release
critical, then that package should not be in the release while it
is known to contain that bug.
Pat
--
Patrick Ouellette
pat@flying-gecko.net
kb8pym@arrl.net
Amateur Radio: KB8PYM
Reply to: