[Rock-dev] Flavours, freezes, updates

[Jakob Schwendner]

Hey,

some of this stuff has been discussed in "The issue with Rock" thread, but I am
starting a new thread here to maybe try and focus this a little bit. Lets say
this is more a collection of thoughts and maybe I'll come to a conclusion and a
proposal in the end. Lets see. I haven't really been thinking or reading on the
philosophy of rolling releases before, so forgive me if I state some obvious
things.

What we call flavours are really synchronisation points between the different
repos. Each of the three flavours is a moving head. Master moves in small steps,
next and stable move in larger steps. The contract is that packages that are on
the same head work well together and are tested also through the build server.
We don't have version numbers and afaik we don't really use any tags or the like
to pin down specific versions.

The current way of how project work is performed is that some project specific
repos including the buildconf are generated, and the project is started. Lets
call this the entry point for that project. We recommend using the next flavour
for this, because its supposedly more stable than master. Note that stable means
two things in this context. One is that it is less frequently updated, and so
less likely to have build errors introduced, and two that the code has been
around longer and might be less likely to have bugs.

Once the project gets going a number of things happen. The project specific
packages are developed and advance, and the non-project - lets call them rock
packages - advance as well. They introduce new features, resolve bugs, create
new bugs and incompatibilties. This happens on both the project side, and the
rock side. People working on the project will perform frequent autoproj updates,
to get what their coworkers have been working on. They will also get the stuff
their current flavour is tracking. If its master, it could be a compile error
that ruins the checkout just before the demo. This is why we recommend to track
next, because its less likely here.