[cut-team] CUT discussion summary for -project@

[Lucas Nussbaum]

On 01/09/10 at 00:55 +1000, Anthony Towns wrote:
> On Tue, Aug 31, 2010 at 22:24, Lucas Nussbaum <lucas at lucas-nussbaum.net> wrote:
> > However, there are several different proposals on what we would actually
> > want to do.
> 
> While that's true, I don't see what the point of a poll is?

CUT and rolling both involve changes in many areas of Debian. I think
that it is important that the decision on moving forward into one or the
other direction is taken after a discussion of the project as a whole,
and taking the project members' opinions into account.
Both approaches will add some burden on each maintainer, because, in the
case of snapshots for example, they will receive bug reports for the
version in the snapshot, and are expected to help with security support.

> > Proposal A: Users install and use snapshots of testing made every 3-to-6 months
> > Proposal B: Users install from snapshot, and then update to and use testing
> 
> We can do both of these by providing snapshots, anyway -- why choose?

I think that you are too focused on the technical aspects of the
discussion. Of course, even with Proposal A, users are free to upgrade
to testing if they want to. The question is whether we are going to
advertise (and recommend) that path.
None of the above poses any strong technical challenges. There's some
work to do, sure, but nothing really new. The big issue is to create
something that works on the long term, with the support of the project,
and that is successful in terms of user adoption and satisfaction.

To answer your question specifically:
- if we do A but not B, we put effort on security support of
  snapshots, and general QA when creating those snapshots. We will
  probably discover that if we just pick a "good" date to snapshot
  testing, we won't get something of sufficient quality to be
  interesting. (Ubuntu basically snapshots unstable, then stabilizes for
  4 months before releasing!). Also, we would test upgrades from
  snapshot to snapshot, not necessarily from snapshot to testing.
- if we do B but not A, we don't put any effort on security support for
  the snapshot (unless a very serious issue that can be exploited during
  installation comes up), and limit our QA efforts to installation.
  But we need to put effort on testing security support.

> > Proposal D: A + B -- Users use either snapshots or testing
> 
> How would we possibly have snapshots without users having this choice?

They will have the choice to manually upgrade, but that doesn't mean
that we will support/test that.

> The only question is how convenient the choices will be, and that's
> not really something that has to be decided before we've got something
> workable.

... in a typical bottom-up approach. While I think that the discussion
should happen in a top-down manner, on -project@, before we rush to
implement things and drop them on the rest of the project.
> 
> > Proposal C: new suite: "rolling". Users install from snapshot then upgrade to rolling
> 
> This implies doing a snapshot too, and as far as I've seen there's as
> many different definitions of what "rolling" would actually mean as
> people interested in it.

I don't think that's true. I re-read all the mails in the mailing list,
and can agree with basically everything Raphael wrote, for example. But
if you think that my summary is not accurate, or not precise enough,
please help fix it.

> > Proposal E: A + C -- Users use either snapshots or rolling
> 
> How would we possibly have snapshots + rolling (as per C), without
> users having this choice?

In B and C: snapshots are not security-supported (except for d-i + apt)
In A, D and E: snapshots are security-supported.

> Please don't get me wrong -- a summary's a great idea, and I'm all for
> polling and getting wider feedback; I just don't see the value in this
> particular question. I would've thought it'd be better to say "there's
> two approaches we're considering: making testing snapshots available,
> both for direct installation as a regular 3-6 monthly release without
> extended support and as a means to more directly and easily install
> current testing; and creating a new "rolling" suite that provides some
> different tradeoffs compared to testing, such as ...", just so people
> know where things are up to.

One of the problem with testing is that there's disagreement on whether
it should be recommended to users. The project doesn't recommend it in
its documentation, but some DDs do, while some other DDs recommend not
using it. I think that we should avoid the same problem, and determine
what the project should recommend.

> If all the options we're considering really do involve setting up a
> testing-snapshot, we should just get on with that, afaics?

That's solving the technical issue, not the social one. Sure, it's
useful if someone does it now. But we also need to work on the social
aspects.

Lucas