Re: [boost] [git] neglected aspects

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

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

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

Sorry, I don't understand what you mean by a "transparent image."

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

Why do you think that? (you give up pretty easily!)

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

Well, you don't need to list "exact commits".  A tree-ish could be a
branch name, so every change on that branch gets tested.  I suppose that
if you're checking in known-broken work it might make sense to have a
special notation in the commit message that would prevent that commit
from being tested when it appears on a feature branch.

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