[cut-team] Where do we go from here?

[Michael Gilbert]

On Thu, 23 Sep 2010 17:10:30 +0200, Lucas Nussbaum wrote:
> On 23/09/10 at 15:04 +0200, Raphael Hertzog wrote:
> > Are you ready to work on rolling? If yes, do you have conditions?
> 
> Yes
> 
> > I am. I can help writing the code to pick updates from testing
> > into rolling and feed the result to dak. I can help managing
> > the direct flow of packages that would not go through testing (e.g.
> > chromium and other packages that we want in rolling that are not
> > in testing).
> > 
> > I would prefer if rolling's rules were relatively close to testing so that
> > it can supersede it one day, at which point testing would become a branch
> > of rolling that starts at freeze time.
> 
> Agreed. I'd like to start with the current testing transition rules, but
> I also would like us to keep an open mind about opportunities for
> diverging from the current testing rules.

I apologize ahead of time for perhaps slowing down the inertia again,
but wouldn't it be prudent to consider other options for rolling before
jumping into an implementation?

So, I think that the core problem for rolling is that:

  1. Packages in testing sometimes disappear.

I think there are at least three options that could address this; both
with advantages and disadvantages.

  a. New "rolling" suite that retains testing removals
     - advantage: easy to install
     - disadvantage: split user base / split developer effort
     - disadvantage: very little difference wrt to testing, so why have
       a whole new suite?

  b. New "testing-removals" or "testing-backports" suite that contains
     only missing testing packages (and their dependencies), which are
     manually recompiled from unstable (just like stable backports
     gets recompiled testing packages)
     - advantage: no splitting of user base or developer effort
     - advantage: a whole lot less duplication
     - advantage: only stuff that has an interested backporter gets kept
     - disadvantage: more manual work since each package needs a
       backporter

  c. Scripts for mixing and matching testing snapshots that once had
     the now removed packages from snapshot.d.o
     - advantage: no new suites needed
     - advantage: infrastructure already exists
     - disadvantage: scripts don't exist
     - disadvantage: may be hard to come up with a user-friendly/robust
       tools

Best wishes,
Mike