[cut-team] Rethinking CUT (again)

[Marcos Marado]

Picking back the discussion regarding "what is CUT trying to solve?", there
were eight items identified:

>     (1) people who could be running testing right now, but aren't
> because of non-technical issues (misplaced concern about security,
> fear from the name, insufficient publicity, negative reactions from
> DDs)
> 
>     (2) people who want to run testing right now, but find it
> technically difficult because of the installation and upgrade path
> (both the initial install stable, upgrade to testing; and the daily
> upgrades of testing forever after)
>
>     (3) people who already run testing, but find their systems aren't
> usable in the way they need it to be (from a quality perspective, ie
> packages are there but don't install/work at an acceptable standard)
> 
>     (4) people who already run testing and want newer software from
> unstable (that would be fine on their machine, but is blocked by
> britney for other reasons -- eg transitions, issues on other
> architectures, etc)
> 
>     (5) people who already run testing/unstable/experimental and want
> newer software from upstream (that is unavailable to them because of
> release concerns rather than stability concerns)
> 
>     (6) the installer team, who find it overly difficult to do beta
> releases against testing and get useful feedback (because it takes too
> long to update the beta to fix bugs due to britney delays; because
> betas get rendered obsolete automatically by testing updates)
> 
>     (7) the release team, who have to worry simultaneously about
> people using testing/unstable wanting new software (cases 4 and 5), at
> the same time they're trying to stabilise the collection of packages
> for a stable release
> 
>    (8) people who want a faster moving operating system than stable, but
> don't want the breakage that comes during the daily testing upgrade
> treadmill.

Here are my thoughts about the problems:
1) It isn't exactly clear why these users have a problem needing to be fixed.
   It is possible that, where it's read "users who could be running testing",
   the actual meaning is "users who want to run testing". If that's the case,
   please read 2).
2) So, we can mix up 1 and 2 together as "people who want to run testing, but
   can't - either for technical or non-technical reasons". In particular, both
   technical and non-technical reasons pointed are things that nowadays define
   what "stable" is, so I boldly rename 1) and 2) as "people who want to run
   testing, but want it to be just like stable", or, in other words, "people
   who wants testing to be stable", or, in other words, "people who want a new
   debian release, and want it *now*".
3) People who are running testing but want it to be as stable as "stable" is.
   Can be satisfied with 2) (in other words, "people who want a new debian
   release, and want it *now*".
4) People who are running testing and want things from unstable. If testing 
   was stable, they would be people running stable and wanting things from 
   testing. Now, this is a different group than (1,2,3), but might have the 
   same solution.
5) People who want stuff even more experimental than "experimental". I don't
   see how CUT has anything to do with this - really - but I think there might
   be a solution for this - just something different from the solutions for 
   the previous items.
6) The installer team would benefit if they had an allways-working testing
   installer.
7) The release team is pressured to both have a stable "stable" release, and 
   to have a smaller freeze stage (to let new stuff enter into testing).
8) People want a "faster-than-stable moving operating system", but they want 
   it as stable as stable is (actually, I think this is the same as 3)).

My thoughts about possible (and possibly less disruptive) solutions:
a) If we identify (1,2,3,8) the same "meta-issue", we can fairly assume that 
   it would be solved automaticly with a quickier pace of stable releases. 
   Mind you, it would have to be without taking anything from what makes 
   Debian stable the rock-solid-stable it is and we love, so this would have 
   to be achieved by having less Release Goals for each stable release. If 
   this solution for (1,2,3,8) was to be adopted, then it would also 
   automaticly be a solution for 4) and 7).
b) I actually have some ideas (probably silly, I know) about how to fix (6),
   but first, I would really like to know, from the installer team, if I)
   they really feel that this generally is a problem, II) if they can describe
   in more detail what their problem regarding the testing installer is, and
   III) if they have any idea of how to fix this, if they think it is a
   problem that can be addressed internally, or if it would benefict from 
   outside help (being it from CUT or any other Debian change). This is, IMHO, 
   an important issue, but one that we don't need to address the same way we 
   are addressing the rest of the issues. In the other cases, part of the 
   problem resides that we're trying to solve issues from users and potential 
   users, issues that perhaps they don't even know they have. In this 
   particular issue, we're trying to solve a debian-installer issue, so it is 
   obvious that we should start by asking them "hey, do you have this 
   problem?".
c) Finally, 5) (the "more bleeding than experimental" scenario). I also have
   some thoughts on how to solve that, but I feel I might have misunderstood
   this item, and this isn't about people wanting "more bleeding than 
   experimental" stuff after all. So, to understand... some of you seem to 
   think that CUT, and in particular "rolling", to address 5). How do you see 
   CUT or "rolling" addressing it?

I know I must be wrong somewhere here. Can you tell me where?

Cheers,
-- 
Marcos Marado