Re: [boost] [Git] Documentation for Git and Modular Boost conversion

Subject: Re: [boost] [Git] Documentation for Git and Modular Boost conversion
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2012-12-16 14:12:11

Peter Dimov wrote:

> I wonder how testing will work. Will the "develop" and "master" branches of each repo be tested? 

I think I can answer this one, if I rely directly on the GitFlow 
branching model [1]. It would be great if somebody from the 
modularisation team could check my answer and my line of reasoning.

The master branch will not need to be tested frequently, because it 
will only contain final release versions. In fact there will probably 
be a policy that you may only merge into master when the candidate 
release version of your library has already been verified to pass all 
unit tests. Only prior to a global Boost release the master branch of 
the superproject will be tested, and if any subprojects turn out to 
conflict this will call for some hotfixes on the respective 
subprojects.

So frequent, regular testing will only take place on the develop 
branch.

When a library is heading for a new release version it will fork a 
temporary release branch from develop. The primary purpose of that 
branch is to remove all remaining errors, before merging into master 
as well as back into develop (the library version in the release 
branch is the candidate release version that I mentioned above). 
Obviously that branch will have to be tested as well; or perhaps 
temporarily *instead of* the develop branch. I don't know whether 
there will be infrastructure that detects the presence of release 
branches automatically (this should be possible if all subprojects 
adopt a common prefix for release branches), or library developers 
will have to request that their release branches be tested.

An alternative plan could be to have the testing team /only/ do the 
automatically detected release branches and the pre-global-release 
testing on the master branch, and make testing on the develop branch 
purely the responsibility of the library maintainer. This would 
relieve the burden on the testing team but might present library 
maintainers with unanticipated problems when they fork a release 
branch. In order to compensate for the latter, there could be an opt-
in policy where library maintainers may request test runs on any 
specific branches of their choice.

The latter procedure is probably the most convenient for all parties 
involved, but might als be the most challenging to realise.

HTH,
-Julian

_____

[1] http://nvie.com/posts/a-successful-git-branching-model/