Boost logo

Boost :

Subject: Re: [boost] [git] neglected aspects
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2012-03-01 09:36:30

(Citation levels: Dave - Julian - Dave - Julian)

>>>> [...]
>>>> How does this approach compare to the one discussed in
>>>> ?
>>> 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."

Oh. I think it was explained at the top of the message I pointed to,
though. Basically the "testing image" is just a working copy of the
(presumed monolithic) Boost tree, but not from one branch; most
subdirectories come from the (super-project) develop branch, while
others may come from any feature branch that the corresponding
developers happened to "subscribe for testing". For a more complete
explanation I think you could best just (re-)read the discussion that
led up to that post, starting here:
you could from there follow the bottom "Reply:" after every message,
which will bring you to the end in 8 posts.

>> 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!)

Basically, from what you said the planned Ryppl approach seems more
- developers can subscribe multiple branches to be tested instead of
  only one (which implicitly defaults to the develop branch);
- there is a possibility to explicitly state which commit should be
- test slave owners can flexibly opt out of certain branches while
  still testing the other branches of the same library.

I didn't mean to "give up", though. My proposed realisation of
Thomas' idea is much simpler and seems more concrete. It's almost
guaranteed to work given a "conservative" gitflow reincarnation of
the current monolithic Boost tree. It might also work with a
modularized Boost, in which case I'd consider it some kind of
"primitive predecessor" of the planned Rypple testing model. But I
didn't think very hard about the latter possibility.


Boost list run by bdawes at, gregod at, cpdaniel at, john at