On Wed, 2013-04-03 at 12:19 +0200, Svante Signell wrote: Correction: Of course CUT should be testing during no freeze. If testing remains unstable(t-dt) during a freeze it is still CUT. Otherwise CUT can be defined as unstable(t) or "new_release"_RCx.
> I think it is "new" in the sense it adds a new dimension to the problem. > I'm repeating the proposal again here, a little differently compared to > before: > > t is current time. > dt is the delay for packages to go from unstable to testing. > T0 is the time for a freeze leading to next release. > dT is the time from freeze to next stable release. > T1 is the time the last stable release was made. > RC0, RC1, ... are release candidates for next stable. > > - experimental: > as before: experimental(t) > > - unstable: > never frozen = unstable(t): Here we have the CUT :) And packaging of new > upstream releases are not hindered by the freeze period. > > - testing: > Case 1) No release: testing(t) = unstable(t-dt) > Case 2) Release: testing(T0) = new archive called e.g. > "next_release"_RC0, then RC1, ... until the last RC bug has been > squeezed out leading to next stable. > > - stable: > Case 1: No release: stable(t) = "previous_release"(T1) (of course with > security updates, etc.) > Case 2: Release: stable(t) = testing(T0+dT) (see above). > > Of course a lot of details have to be squeezed out but the above covers > the main idea. What do you think? > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1364991039.2302.143.ca...@s1499.it.kth.se