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

Alan Alpert alan.alpert at nokia.com
Wed Aug 8 10:14:43 CEST 2012


On Tue, 7 Aug 2012 18:59:28 Abecasis Joao wrote:
> 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.

Bug fixes and regressions, I presume you mean. 
> 
> 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.

Let me try again then, zoomed-in on the 5.1.1 section. Because reading ascii 
art just doesn't seem to be my specialty.

------------------------------------ fire-hose
                              |
------------------------------+----- leaky-faucet
                        |             
------------------------+----------- dripping-bucket
                   \                  
                    5.1.1                  

~2 Minutes |-----------------|

So the 5.1.1 release is tagged before leaky-faucet merges to beging 5.1.2, and 
that merge happens before fire-hose merges into leaky-faucet? And that merge 
from fire-hose -> leaky-faucet around the time of the 5.1.1 release doesn't 
reach dripping-bucket until the 5.2.0 release? If so, I might finally have 
figured it out.

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

I like the idea of strict time based releases, but given the past minor 
releases 6 months is optimistic. That said, we could easily have smaller minor 
releases that are actually minor for a change. I'm realizing now that this 
design is intended to transition from feature-based releases to time-based 
releases. Since quality is the casualty in both schemes, I'm less worried 
about that now ;) .

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

Okay, that addresses my other concerns. This does sound like it needs us to 
work in branches a little more, could we please get a better process for 
gerrit branches than "ask a gerrit admin"? Or just relax the 
http://qt-project.org/wiki/Branch-Guidelines to be more permissive of working 
in gitorious.org branches.

Thanks for taking the time to explain it to me. I think I understand it now, 
and it sounds like a good idea. Especially after 5.0.0, which is a good time 
for a developer mindset change.

--
Alan Alpert



More information about the Development mailing list