Re: [boost] [git] neglected aspects

Subject: Re: [boost] [git] neglected aspects
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2012-02-11 08:04:30

On 02/11/2012 01:42 PM, Julian Gonggrijp wrote:
> 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.

Right, that all makes sense. However, the whole branching stuff seems 
like a lot of overhead (even if the tool is able to handle it very 
good). Mind you, we, the developers don't always have all the toolchains 
available on our developing platforms.
What would make this whole branching very cool is if we could somehow 
tie it with testing such that we are able to tell the testrunners to use 
our feature branch to run the tests (of course this must be automated in 
a way). I think in this scenario, a modularized boost will come in very 
handy ... Think of the VHDL model, you have unit tests, but the module 
under test might be very different, though the unit tests stay the same. 
This is something i would really like to see.

> 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
>
>
> _______________________________________________
> Unsubscribe&  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost