[cut-team] Rethinking CUT

[Bruce Sass]

On September 9, 2010 08:13:36 pm Michael Gilbert wrote:
> Hi,
>
> I've been thinking for a while now about the CUT ideas currently
> floating around.  The problem I see is that there are a lot of ideas
> for solutions but no concrete (root cause) list of problems those
> solutions are meant to address.  Without this all-important first
> step (often used by engineers in problem-solving), I think the
> results will miss the mark, and in the process compound the work for
> many teams without a whole lot of benefit.

I think you have the right kind of idea, but are applying it to the 
wrong problem--it is Testing itself which is fundamentally broken and 
should be fixed. CUT is a partial (potentially baroque) attempt to work 
around that fact... and one which would not be necessary if Testing had 
been done right.

The main idea behind what became Testing was to come up with a way for 
DDs to continue developing newer software while a release was being 
prepared. The possibility of having a constantly usable repository of 
fresher software than what was in Stable was brought up as an 
additional reason for changing the Unstable + transitory Frozen + 
Stable development model which was in use at the time.

Clearly neither of those goals were achieved by the solution which was 
put in place--and, AFAICT, the reason it turned out that way was pretty 
much exactly the problem you see--people are jumping into 
implementation details before the design work has been finished. IOW, 
the idea of, `top down design, bottom up programming', seems to have 
been forgotten or tossed out in favour of a more hackish methodology.

the point:
It would be far better to work out how to "fix Testing" so that it is 
constantly usable than come up with a new side project that only does 
part of what Testing was supposed to.

so...

The concrete list of problems has been made: Unstable gets closed to new 
packages when a release is being prepared; there is no constantly 
usable archive of better quality than Unstable which is fresher than 
Stable.

The next step should be to identify the required stages software must go 
through as it progresses from upstream release to Stable Debian 
package. Doing that is likely to both, illustrate why Testing is 
broken, and suggest the structure a new model should have if it is to 
succeed.

E.g., lets say the stages of development has the following chain:

initial packaging -> packaging bug fixes -> integration with other 
packages -> software bug fixes -> release

Superimposing the current development model on top results in:
 |
 V
Unstable = initial packaging + packaging bug fixes
 |
 V
Testing = integration with other packages + software bug fixes
 |
 V

Which implies that: Testing is not constantly usable because it is 
expected to do the integration with other packages task, something 
which necessarily results in an inconsistent archive from time to time; 
Unstable can't be disconnected from Testing because that is the only 
path available for packages to get into Testing (which begs the 
question: why must packages which have passed through Unstable once 
before be required to do so again?)

The suggestions for a new model are: separating the integration and 
software bug fixing tasks will eliminate the not-constantly usable 
problem; a path to the integration stage which doesn't necessarily 
involve Unstable will allow for the required disconnection.

One possible solution:
 |
 V
Unstable = initial packaging + packaging bug fixes
 |
 V
Testing = integration with other packages   <-- *
 |  
 V
Rolling = software bug fixes
 |
 V

* =  feeds from here and "software bug fixes"

Of course I don't expect it is that simple in reality--all I can see is 
the forest, it's the DDs who know what species of trees exist...

- Bruce