[Development] Setting up time-based releases for the project

[Alan Alpert]

On Mon, 6 Aug 2012 22:13:30 ext joao.abecasis at nokia.com wrote:
> Fire-hose is a development branch, things may be variously broken at all
> times. Typically, developers in this mailing list will be tracking that
> branch.
> 
> Leaky-faucet is deemed beta quality and somewhat more stable. At the very
> least it shouldn't break as often. We can expect that more people will be
> willing to track this branch with their own development.

This is the part that I don't quite understand. This makes it sound like Fire-
hose is the branch for destabilizing changes. Particularly destabilizing 
change sets are of course in their own branch, but the large numbers of 
normally destabilizing changes will make fire-hose mere Alpha quality at best. 
But then Thiago's email then said that fire-hose should be 'always ready for 
beta', which seems contradictory.

As I interpret it, the bump in quality comes from merging fire-hose to leaky-
faucet some time before the release. Unfortunately, I didn't get any extra 
detail when I zoomed in on your ascii art. Here's my zoomed in version of the 
diagram:

----------+----------------- fire-hose
           \
----------+---------+------- leaky-faucet
                     \
--------------------+------+ dripping-bucket
                           \ 5.1.0
~2 Months |-----------------|

Note that we also seem to disagree on the time scale, but that's what '~' is 
for ;) . Am I correct in assuming that merging fire-hose to leaky-faucet drops 
the quality of leaky-faucet to whatever fire-hose may be, and then developer 
focus shifts to leaky-faucet for stabilization (while destabilizing elements 
continue to flow rapidly into fire-hose for the next release)? How much lead 
time do we allocate per release? And what happens if we slip, because we 
couldn't get it to beta quality in time?

> > If we move the release testing onto leaky-faucet, then dripping-bucket
> > contains only the latest release, with at most a critical patch or two.
> 
> That depends on whether we consider that typical patch release traffic has
> an impact on release readiness. (Can bug fixes introduce new regressions?
> :-)

When applied in haste? Roll a d20 :P . More seriously, it sounds to me like 
dripping-bucket is just there for the release manager to have a further 
measure of control. But if that's where the packages are generated from, 
that's where the release testing will happen no matter how few patches we try 
to accept on top.

On a less important aspect, can we use less metaphorical names? master, beta, 
release perhaps? trunk, stable, release-managers-private-stash? I don't like 
starting the bike shedding part early, but since your metaphors aren't really 
working for me I think other names might allow for more clarity.

--
Alan Alpert