Re: [boost] [git] neglected aspects

Subject: Re: [boost] [git] neglected aspects
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2012-02-29 15:04:57

Dave Abrahams wrote:

> 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. [...] 
>>> 
>>> 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:
>>> 
>>> [...]
>>> 
>>> 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 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.

I'm not sure whether this is correct. The script I outlined does 
involve a git merge, but it's only a temporary one in the working 
directory that will be reset afterwards. The purpose of the script is 
not to merge (in fact the intent is to leave all branches unchanged) 
but to provide a transparent image to the testing volunteer, which 
includes exactly one branch of each Boost library.

So my impression is that the planned Ryppl testing model and the 
testing model concept from the thread in the Boost archives do have 
similar goals, i.e. to automate testing of heterogeneous selections 
of branches from the various libraries. After some more thought I 
suspect the planned approach from Ryppl is superior, though. :-)

> 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 was aware of that; the idea would be that a library developer 
pushes the feature branch to be tested to the public repository when 
the last commit on that branch is expected to be stable, then waits 
until it's tested before pushing again. After all, the developer 
isn't interested in testing completely broken commits. I think this 
is the same thing that the planned Ryppl approach aims to accomodate 
for by listing the exact commits to be tested.

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

/No Boost supertree at all/, that was an eye opener for me. It seems 
so natural to have a supertree, but I now realise it's not that 
obvious.

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

I was going to respond to your previous email and ask why there is 
still a Boost "super-project" at https://github.com/boost-lib , but 
you answered that question over here.

Thanks.
-Julian