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
>>> 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
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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk