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

[Michael Gilbert]

On Fri, 24 Sep 2010 08:02:49 +0200, Lucas Nussbaum wrote:
> 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.

I think that I worded this a bit too restrictively.  The ideal solution
would be to allow any/all packages that have interested backporters
into testing-backports (of course as long as those are accepted by the
testing-backports admins).

I think that providing backports as a separate repository is a much
simpler solution than a completely new suite.  Users that want "rolling"
updates during the freeze can simply add an additional apt repository;
rather than switching to a whole new suite.  Plus the new suite would
be comprised of mostly duplicated testing packages + a few backports.
Why merge the two when its much more straightforward to keep them
separate?

Best wishes,
Mike