Re: Temporal Release Strategy
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?
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?
Gunnar Wolf - email@example.com - (+52-55)1451-2244 / 5554-9450
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF