[cut-team] Rethinking CUT

[Raphael Hertzog]

Hi,

thanks for this long but interesting mail.

On Fri, 10 Sep 2010, Colin Watson wrote:
> I realise perhaps as much as anybody that Ubuntu's development model is
> very different, but what we do there is: every few weeks, we say "OK,
> we're rolling a new milestone release now", we get the archive
> installable, sync up kernel versions with d-i if necessary, fix anything
> that's broken in d-i (usually not too much), do a few test runs, and
> mark it as a milestone release (though media only, we don't snapshot the
> archive).  I've been handling d-i for nearly every Ubuntu milestone
> release for six years and I haven't burnt out.  Obviously the fact that
> I draw a paycheque for it helps, but it's really just not that painful.
> So, why is it so hard in Debian, with basically the same codebase?

Let's try to answer this question: I don't have the answer but I have
ideas.

Maybe because of the supplementary architectures that we are supporting?

This brings me back to the need to support less architectures in
"rolling" and "cut" and have a model where only i386/amd64/armel are
blockers. And other arches can follow if they have the required
resources but they would not be allowed to block.

I guess that getting a new kernel ready for d-i is a lot less pain if you
have only 3 arches to care about.

Same goes for testing upgrades between CUTs. And for making sure any
manual security update gets built for the arches that we care about.

And it would also mean that the rolling distribution could be more rolling
than testing because some migrations would happen sooner (and because
some arch-specific RC bugs could be ignored in theory, though I think
this feature exists neither in the BTS nor in britney).

If we combine everything, I have the feeling that the global proposal
starts shaping up. I like this.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
                      ▶ http://RaphaelHertzog.fr (Français)