Re: Temporal Release Strategy
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.
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.
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.
...But if you come up with an implementation, I'll just shut up :)
Greetings,
--
Gunnar Wolf - gwolf@gwolf.org - (+52-55)1451-2244 / 5554-9450
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Reply to: