[cut-team] Contantly Usable Testing, and Debian "rolling"

[Guido Trotter]

On Mon, Aug 09, 2010 at 03:12:40PM -0400, Joey Hess wrote:

Hi,

> *taptap* is this list on? Alioth may be being slow. I've CC'd 7 people
> who have not subscribed to the list yet. There are currently 9 people
> subscribed to the list.
> 

Yeah, the list is up! :)

> I am interested in both. In particular, I want there to be snapshots
> because they are needed to ensure installation always works and provide
> a firm base, and I want users to be able to easily upgrade to testing
> or similar, and have that also work well.
> 

Agreed on "both". Actually, having semi-supported snapshots also means that
"rolling" is a good target, but gives the option of running a "less-stable"
"more-up-to-date" debian. If we allow DDs to push bug fixes to it (via
backports.org or similar, for example) it means you can have a new-enough
version which doesn't move continuously but just for fixes, until you decide to
upgrade to the next CUT or to testing.

> I don't think these ideas are in opposition, indeed doing each makes
> doing the other easier. Just, I think that snapshotting is the best way to
> get started, because it's an incremental step up from the current d-i
> releases, and wih testing frozen, this is the easiest point in the
> release cycle to make one or more snapshot releases.
> 

And it catches both users who just want a way to install testing and users who
want to run something newish but don't want changes daily.

> So I want to take advantage of the freeze:
> 
> 0. Assemble a team.
> 1. Assemble a snapshot release.
> 2. Publicise that this is available, get users.
> 3. Deal with upgrades. (Someone suggested makign a "weather report" 
>    that detects trouble in testing.)
> 
> That all seems straightforward, and it lays the groundwork for whatever
> we decide to do later.
> 

Agreed. :)

> The release team necessarily has to yank packages sometimes for transitions.
> A suite without such oversight would tend to always lag what is available
> in testing. Especially desktop environments would tend to fall behind
> due to their complex dependency graphs. That is one of the problems I
> have with the idea of adding another testing-like suite, rather than 
> finding ways to improve testing.
> 

So you both want "cut-X" and "rolling"?

> * No accouncements are done for fixes that propigate from unstable, 
>   leaving users needing to dist-upgrade. This is something the CUT team
>   should address.

Yes, it'd be nice if at least the last cut had announcement and cut-security
support.

> I don't dislike it at all, but "cut" is supposed to be at least usable as
> a way to describe both a snapshot and as an acronym to describe a rolling,
> constantly usable testing release.
>  

I believe "cut" reminds more of a snapshot as a name, than something moving.
We can have "rolling" for the moving target if we need any outside of "testing".
But do we? If the cut contains the packages that release team might have
removed, what's missing for testing to be usable on top of it?

Thanks,

Guido