[Release] Release progress

[Keith Hodges]

Keith Hodges wrote:
> Hello All,
>
> There has been a fair bit of progress towards our Sake/Tasks's version 
> of ReleaseBuilder.
And since some still cant see the point of doing it this way. I thought 
I would try a small explanation.

The plan is to change the development life cycle

From...

One person integrates a couple of small fixes -> generates an update - > 
publishes an image
-> observers feedback (by which time the integrator has moved forward 5 
steps) -> go around again -> (in case of a problem the integrator has to 
go back 5 steps to undo a mistake and then go around again).

 From the fix developer point of view, if the fix doesnt work correctly 
they then have to produce a fix for the fix. The resultant "fix" is very 
specific, and cant be used elsewhere.

To...

A. Produce a Test Candidate image from current release + "Tasks", submit 
for test and feedback, improve/add/remove tasks, and build again.

Advantage 1: Tasks can be tested on old images, minimal images, full 
images, production in-use images and the current release. So the release 
work can be used in a pick and mix fashion by those who want to adopt it 
into other places. And each task can be more broadly tested (automated 
one hopes)

[All of the current tasks have been adopted into my main deployed image]

Advantage 2: Task developers, particularly those wanting to do a major 
refactoring are not working with a moving target." The update 
stream-only approach is a moving target.

Advantage 3: Newer ideas such as picking updates from several parallel 
update streams (i.e. DS) can be adopted into this framework.

Advantage 4: A lot of work can be accomplished in parallel and integrated.

Advantage 5: Tasks which do not make it into the release are not wasted, 
but can be used by those who want to use them, or deferred for later 
release cycle.

Advantage 6: A framework is established for future releases, enabling 
future "out of scope items" to be road-mapped. This means we can do some 
actual planning.

Advantage 7: Radical innovations can be included/removed very easily if 
they prove to cause a problem. But more importantly radical innovations 
are more likely with this model.
 
Advantage 8: Tasks which are developed on a minimal kernel image, can be 
tested on full-images. There is no need to wait until someone eventually 
takes the final release, loads all of their packages and THEN finds that 
it doesnt work.

Advantage 9: The overall control of the release progress is not 
constrained by one person. Tasks can be developed independently. The 
final vote on what the release contains can be offered to the community 
(if you dare).

B. Generate a Release candidate as a "simple" incremental change from 
the Current release

Automate the generation of an update from the current release to the 
next release given that the desired result is known in advance.

cheers

Keith