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://listarchives.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