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

[Lucas Nussbaum]

On 23/09/10 at 12:05 -0400, Michael Gilbert wrote:
> 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.

Hi,

I agree that there are other valid ways to address the same goal, but I
think that they are inferior to a new "rolling" suite.

>   a. New "rolling" suite that retains testing removals
>      - advantage: easy to install
>      - disadvantage: split user base / split developer effort

It is likely that a usable rolling will also attract more users. So the
switch is between:
- testing with the current number of testing users
- testing+rolling, with more users, and probably more of them using
  rolling
So I hope that we will end up with *more users* using packages that are
sometimes *a bit different* from the ones in testing. All in all, I
don't think that testing's testing will suffer much from that.

>      - disadvantage: very little difference wrt to testing, so why have
>        a whole new suite?

While 'rolling' will be very close to 'testing' outside of freezes, I
think that the ability to make different choices than for 'testing' is a
key point for something that we want to be usable, and advertised as
such. And the only way to achieve that is through a different suite.
It is also a way to minimize the burden on the release team, since
they would be completely free to choose to break some packages in order
to push a transition, while in 'rolling', we could choose to break a
different set of packages for a different reasons.

>   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

I think that the choice of packages for 'rolling' will end up being more
complex than just 'testing + packages removed from testing'. So limiting
ourselves to that by design is not a good idea.

Also, the use of a single suite makes 'rolling' much easier to support.
If we had 'testing-backports', do we want to support only
'testing-backports + testing', or also 'testing' alone?

>   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

What would be the outcome of those scripts? If they are supposed to be
run by end users, I don't really see how they could user-friendly
enough.

Anyway, I think that we could start working on 'rolling' as an
experiment, without advertising it as a viable alternative to testing
yet.  It's likely that when we will get our hands dirty, we will
understand whether 'rolling' is a viable implementation, or if we should
switch to alternate solutions.

- Lucas