Boost logo

Boost :

Subject: Re: [boost] [git] neglected aspects
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2012-02-11 07:42:20

Daniel James wrote:

> On 9 February 2012 13:46, Julian Gonggrijp <j.gonggrijp_at_[hidden]> wrote:
>> Daniel James wrote:
>>> On 8 February 2012 14:37, Julian Gonggrijp <j.gonggrijp_at_[hidden]> wrote:
>>>> This might have been mentioned before, but gitflow seems to be ideal.
>>>> See [5] for an explanation of the branching model and [6] for an
>>>> optional tool which automates workflows that adopt the model.
>>> The problem that we face with something like gitflow is testing. We
>>> only have the infrastructure for testing two branches so we can't
>>> adequately test feature branches.
>> Stop right here. You seem to be writing this on the assumption that
>> with git, we'd still have two separate source trees, one for the
>> development branch and one for the release/master branch. One of the
>> exciting things of git is exactly that you can abandon that situation.
> I was writing about the limits of our regression testing system, not
> the limits of our version control system. We need to frequently run
> our tests on compilers and platforms that we don't have access to, so
> we rely on volunteers running the test suite regularly. They currently
> only do that on two branches.

So the perceived problem is that it would take too much time for the
volunteers to check out all of the numerous feature branches that
might exist at any given moment and test all of them, in addition to
the develop branch and the current release branch. The practical
consequence is that features under active development cannot be tested
on all platforms until they're merged back into the develop branch.

Here's why I think this isn't a real issue.

Generally, when you make a change to your project, you do it in two
stages. First, you implement the changes; next, you keep tweaking and
polishing your work until it does the right thing on all relevant

The first stage is typically something you'll do in a feature branch.
During the work, you run unit tests on your local platform to
establish that your approach should work in principle.

If you reach the end of this stage, you'd generally expect that your
changes will work on other platforms as well, with some corrections.
So that's the right moment to merge back into develop and continue
your work over there.

The tweaking and polishing stage is then facilitated by the fact that
the develop branch is regularly tested by volunteers. You can still
use temporary feature branches of shorter duration if some compiler
needs more attention; just merge them back before the next regular
test session is run. Such a workflow is completely normal with git.

Concluding, the volunteers still only need to test two branches, i.e.
develop and the current temporary release branch (if there is one).
The only difference that feature branches make to testing, is that
changes for which testing on all platforms doesn't really make sense
yet are isolated.


Boost list run by bdawes at, gregod at, cpdaniel at, john at