CUT and stable releases Was: Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Tue, 2013-04-02 at 17:24 +0100, Adam D. Barratt wrote:
> On 02.04.2013 16:35, Svante Signell wrote:
> > The best solution would be having unstable _never_ frozen, at the
> > cost
> > of another repository during the freeze period. This was proposed
> > some
> > time ago, see
> > http://lists.debian.org/debian-devel/2013/01/msg00273.html
> > repeated here for convenience:
>
> That's a contentious definition of "best". You also appear to have
> somewhat missed the point of my response to that original message, i.e.
> <URL:http://lists.debian.org/debian-devel/2013/01/msg00274.html>
As I replied to you in
http://lists.debian.org/debian-devel/2013/01/msg00275.html
I did _not_ propose to remove testing!
> > i) experimental being really for new stuff
> > ii) unstable unfrozen always:
> > - stable+1: if no freeze -> testing after xx days as before
> > - stable+1=unstable frozen at freeze time: if during freeze ->
> > testing
> > -> stable
> > - stable+2: if in freeze -> unstable
> >
> > And the frozen unstable/testing repository could cover a subset of
> > the
> > packages in unstable: The "good ones". That would effectively reduce
> > the
> > freeze period.
>
> I'm still struggling to see how this is fundamentally different from
> the "frozen" suite which "testing" was introduced to replace, more than
> a dozen years ago. As per my earlier message referenced above, see
> <URL:http://lists.debian.org/debian-devel/2000/08/msg00906.html> for
> some detail of why "frozen" didn't work.
It's not fundamentally different, but still different. And we can
easily achieve CUT too, see below :)
> > As proposed in the thread the idea should be written down at
> > http://wiki.debian.org/ReleaseProposals
> > Since this idea is new as far as I could see it's time do do that.
>
> FSVO "new".
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 packahing 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?
Reply to: