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

joao.abecasis at nokia.com joao.abecasis at nokia.com
Tue Aug 7 10:59:28 CEST 2012


On 7. aug. 2012, at 02:45, Alan Alpert wrote:
> 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.

Given that these are all common shared branches they should not be getting
half-baked features in. For small features it's feasible to allow that they'll
be built incrementally over a couple of commits. Anything beyond that is a
good candidate for feature development in a separate branch. These should only
hit the shared branch when they are ready for prime-time, admittedly this is
also when those features get wider exposure and more issues are found.

When you mention "destabilizing" changes the truth is most of the time we
don't know which ones those are. Here, we try to increase stability by
limiting the type of changes that go into each branch: only regressions should
be fixed in the leaky-faucet branch, which is similar to the patch release
policy we tried to keep in the past.

The fact that we build up a predictable release schedule means there is less
pressure to rush changes in. You know exactly when your feature will make it
to a release, as long as you get it in good shape and into fire-hose.

> 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 |-----------------|

That's not the zoomed version, and you don't need it. Admittedly the original
graph had a bug by showing '+' on both sides of the merge, where only the
destination should have them. Here's a fixed, stripped down (non-zoomed)
version:

     ------------------------------------ fire-hose
                   \
     ---------------+-------------------- leaky-faucet
          \        \        \        \
     ------+--------+--------+--------+-- dripping-bucket
          \        \        \        \
           5.1.0    5.1.1    5.1.2    5.2.0

(does it help?)

Notice how merges coming from the branch above happen after a merge to the
branch below. This gives a lower bound of 4 months for a change to make it
from fire-hose to a release and an upper bound of 10 months, depending on when
the change gets into fire-hose to begin with.

> 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?

The goal here is to get to strict time-based releases, which means we don't
slip the schedule. If we make a lower quality 5.x.0 release, quality will
improve for the 5.x.1 and 5.x.2 releases.

This is all assuming we *want* to have a minor release out every 6 months. If
we don't, then all discussion is pointless.

After we have tried this setup, and *if* we feel quality is consistently down,
then we need to make adjustments. We can adapt policies, be stricter about
enforcing those policies (e.g. through the CI system), or require higher
standards when accepting features into the fire-hose branch.

You also mentioned developer focus. I think it is fair to assume we have
developers with different focus and priorities -- and that's ok. Having the
branches always open means you are in charge of your focus (next minor
release, next patch release or simply trying to get your feature in).  It is
still expected that any developer introducing a feature will (try to) see it
through to a release. It is also expected that everyone prioritizes release
critical bugs related to their own areas of expertise.


João




More information about the Development mailing list