[cut-team] Rethinking CUT (again)
mindboosternoori at gmail.com
Wed Sep 29 14:20:50 UTC 2010
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
> (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
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
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
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
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?
More information about the cut-team