Re: [cut-team] Time to merge back ubuntu improvements!
On 01/12/2013 08:59 PM, Svante Signell wrote:
> On Fri, 2013-01-11 at 16:05 +0100, Stefano Zacchiroli wrote:
>> Doesn't this diminish significantly the advantages of CUT? Back in the
>> days of the CUT discussion, one of the main "issues" associated to
>> testing is that it stops rolling during freezes.
> As unstable does! As a user of testing and unstable I think it is very
> unfortunate that packages in unstable practically stop rolling and no
> new (or bug-fixed, except RC) packages are uploaded.
Yeah! I also find it disturbing that we are supposed to upload new stuff to
Experimental. Then during the freeze, there's no distinction at all between
stuff we upload to Experimental because of the freeze, and stuff we upload
to Experimental because we don't consider them ready for Unstable.
> but I assume very many of them are idling
> until the next stable is released. Some are forced to stop by the
Yes. That is annoying, I agree.
> Additionally, not everybody is able to solve all kinds of RC
> Is there a way to solve this problem? For example, when the freeze
> happens, packages in unstable are marked as presumptive packages in the
> new stable release. Then these packages are branched off to something
> that could be called pre-testing or whatever, and sid goes on as before
> the freeze.
Or we make it so that stable+2 (currently Jessie) exists right after the
freeze. SID would then be the staging area for packages and library
transitions for the unfrozen stable+2 (currently Jessie), during the freeze,
instead of stable+1 (currently Wheezy) when not frozen. We would upload
to t-p-u if we need updates to stable+1 (currently Wheezy).
I'm not proposing this change to happen (now or later), just barely listing
what would be possible to solve the problem. I'm not even sure that's the
path we should take, and that depends a lot on the view of both the
release team and the ftp team, and the security team, whom might just
object the lack of manpower to actually implement these changes (and yet
even manage transitions in stable+2 during the freeze of stable+1).
Because if we take that path, it means that during the freeze, we'd have 1
more flavor of Debian to take care of (eg: stable, stable+1, stable+2 and
If there was a choice to make (which isn't even the case), I'd personally
prefer having a longer support for the old-stable distribution.
On 01/12/2013 10:21 PM, Jonas Smedegaard wrote:
> ...and then back to that issue of "maintainers should concentrate on the
> release" again: I do sincerely worry that additional suites _will_
> affect how many of us developers will concentrate on getting the release
Me as well. But how can we know in advance what effect it will have?