Re: [boost] [git] neglected aspects

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

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:
http://lists.boost.org/Archives/boost/2012/02/190269.php
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 
flexible:
- 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 
  tested;
- 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.

-Julian