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

joao.abecasis at nokia.com joao.abecasis at nokia.com
Sat Aug 11 02:58:31 CEST 2012


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

Sure, subject to as yet unspecified policy.

[snip]

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

I see what you mean, and yes, that looks spot on.

(I was using the slanted '\' to indicate commit being merged is actually
coming from somewhere in the past -- i.e., the merge commit has to be
more recent than its parents. So, while merges could go in at around the
same time in all branches, the commits being merged had to come from
before... Or look at Alan's graph ;-)

[snip]

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

I agree, we need to figure out ways to better support and agilize work
in feature branches. Preferably, reviewed and CI-tested feature
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.

Good! :-)


João



More information about the Development mailing list