Re: [boost] [git] neglected aspects

Subject: Re: [boost] [git] neglected aspects
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2012-02-09 08:46:43

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. 
There is only one file tree, and the branches act like "parallel 
worlds" in which that same file tree received different update 
histories. So a feature branch is just another instance of the same 
tree, with the same available testing infrastructure.

> We really do need to test on a wide
> variety of platforms as early as possible. But we wouldn't want to
> merge half done features into the develop branch just to get testing
> (this is one of the biggest problems we have at the moment, changes
> are often in trunk for some time before they're merged into release,
> if at all).

So this is actually an advantage of git: you don't need to merge a 
feature branch first in order to test it.

> A possible solution would be to use the 'develop' branch as the
> equivalent of our current release branch (I'm not sure how to branch
> for release, we might have to do without and just restrict additions
> to develop as we currently do, at least at first) and add another
> 'testing' branch. This would branch from develop, and feature branches
> would be merged into it for testing. [...]
> 
> Or maybe, rather than being a traditional branch, the test repo could
> be created by a script [...]
> 
> This testing mechanism would be fairly separate from the main flow
> structure so it could be provided by an additional tool to gitflow.
> Hopefully wouldn't be too hard to develop. Does that make any sense? I
> know it isn't ideal, but it seems plausible given our current
> infrastructure. And we could work on improving it as we go.

No, no, no. No. Something that seems plausible given the current svn-
based approach would actually make things more complicated and less 
straight-forward. Here's how I think the standard gitflow branching 
model would fit snugly around the current Boost workflow:

- The develop branch corresponds to the current trunk. This is where 
library authors can continually make (small) changes to their 
projects. There is one important difference: when authors decide to 
add big new features, to completely overhaul their library or to add a 
whole new library (basically anything that might take more than a 
day), they fork a new feature branch for that purpose.

- As indicated, the feature branches act like sandboxes where big 
changes and additions can be prepared before they're merged back into 
the develop branch. Or they can just be abandoned if an experiment 
turns out to fail. Authors can run full regression tests within the 
feature branches, since every branch contains the same file tree with 
the same tool configuration.

- The master branch corresponds to the current release branch, again 
with an important difference. In the current situation, trunk is 
merged directly into release, with the (manual) exception of libraries 
that are in too turbulent state, and after that the release branch is 
updated until everything is really ready for release. In the new 
situation, a new (temporary) release branch is forked from develop 
first (which automatically excludes turbulent changes because those 
reside in separate feature branches) and then updated until all tests 
pass (ideally), at which point it is finally merged into master (as 
well as back into develop). So the master branch only includes the 
actual releases, which of course are also tagged.

- As indicated, release branches act like quarantines in which the 
code from develop is made ready for release/merge into master. Again, 
because it's the same file tree the same tools are available. Because 
release branches are only merged into master when the code is deemed 
ready for release, the merge into master can be a trigger for running 
scripts that may be used in the release process. Similarly, commits to 
release branches can be set as a trigger for automatic regression 
testing.

- Hotfix branches can be forked from master whenever a release turns 
out to contains bugs afterall, like the update from 1.46 to 1.46.1. 
Again they contain the same file tree and the same tools, and 
regression testing can also be automated in this case.

- BoostPro might want to use support branches for older releases. 
Again, a support branch contains the full tree with all tools, and so 
forth.

For as far as I can tell, the gitflow model allows Boost to do 
everything it does now, in many cases more elegantly.

-Julian