Re: [boost] [git] neglected aspects

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

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.

HTH,
-Julian