Re: [boost] [git] neglected aspects

Subject: Re: [boost] [git] neglected aspects
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-02-29 13:19:51

on Tue Feb 28 2012, Julian Gonggrijp <j.gonggrijp-AT-gmail.com> wrote:

> Dave Abrahams wrote:
>
>> on Wed Feb 08 2012, Daniel James <dnljms-AT-gmail.com> wrote:
>> 
>>> 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. We really do need to test on a wide
>>> variety of platforms as early as possible. 
>> 
>> The way we plan to handle this with Ryppl is that you check in a testing
>> specification with your project.  The testing specification is just a
>> text file, something like this JSON:
>> 
>>  {
>>    <configname>: {
>>      dependencies: { /* dependency versions */
>>        <libname>: <git tree-ish>, ...
>>      },
>>      cmake: { /* properties passed to cmake */
>>        <key>: <value>, ...
>>      },
>>      platforms: [ <platform-string>, ... ]
>>    }, ...
>>  }
>> 
>> Where you can request multiple configurations to be tested for commits
>> on each branch.  To get your in-development work tested, just publish a
>> feature branch containing a test specification file to your public
>> repository.
>> 
>> The test results are then added to the commit using git notes.
>
> How convenient will that be for the testers? 

If by testers you mean the people that manage machines used as testing
resources, it will not require any manual intervention on their part.
We may eventually need a way for them to specify which tests they are
willing to run, though.  For example, I may want my test slave to "opt
out" out of all tests of feature branches. 

> How does this approach compare to the one discussed in
> http://lists.boost.org/Archives/boost/2012/02/190418.php ?

The message above seems to be (mostly) describing a mechanism for
automatically merging feature branches.  As far as I can tell, the
approaches are apples and oranges, and thus are basically compatible.
We do something like that at Boostpro for handling upstream merges to
Clang.

Once Boost is properly modularized, I'm not sure how important
such a mechanism will be for most libraries, which are maintained by
individuals.  That said, *if* you have to manage lots of long-lived
feature branches, a tool like topgit can be used very effectively along
with git-flow.

There's one important thing about the git-flow model that I'm not sure
you've accounted for, though: on feature branches, completely broken
commits are de-rigeur.

>> I take for granted that we're going to have a modularized boost with
>> a separate repository for each library
>> (<https://github.com/boost-lib>) and each library will have its own
>> develop branch.
>
> This sounds like a situation that calls for git-subtree, but maybe I
> understood git-subtree wrongly.

git-subtree, IIUC, is a mechanism for merging/extracting individual
repository histories into/from separate subdirectories of a larger
repository.  My main question is, why does Boost want to do that?  I
understand why we want separate repositories, but I don't yet understand
why anyone wants a monolithic whole.

On the other hand, I *can* see how it would be very useful as a basis
for the one-time history-preserving modularization step.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com