Re: [boost] [git] neglected aspects

Subject: Re: [boost] [git] neglected aspects
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2012-02-11 09:10:39

Thomas Heller wrote:

> On 02/10/2012 04:31 PM, Daniel James wrote:
>> On 10 February 2012 15:01, Julian Gonggrijp<j.gonggrijp_at_[hidden]>
>> wrote:
>>> Note (3): while this image helps to explain my point in [1], it
>>> turns out from [2] that I didn't actually address Daniel James'
>>> point. I'll return to the testing issue in a new reply to [2].
>> 
>> Having thought about it a bit, it might be the case that I
>> exaggerated the issue. It certainly matters to me, but I'm not sure
>> about other developers. A lot of the newer libraries don't put much
>> effort into supporting the more obscure compilers.
> 
> Well, i still like to believe that one of boost's strengths is the large
> platform support.

++

> This is also the reason why I believe that a branching model is not a
> good solution for boost. Here is why:
> 
> When i develop a new feature i do that on trunk, whenever i feel
> confident that the feature works as i expected it, i commit it. 

Do you realise that what you describe here is basically to make a 
feature branch locally on your computer (but without history), then 
when you feel ready for the polishing stage merge it back into the 
trunk? It's exactly the process I described in my latest reply to 
Daniel James.
You're already doing exactly what you'll do with the gitflow branching 
model, but without two of its advantages: lightweight commits (as 
described in my latest reply to Julien Nitard) and a history of your 
changes prior to the merge into trunk.

> After a
> couple of days the test cycled, and i see on which platforms these tests
> fail and i try to fix it. This is where I have problems with this whole
> branching model, when will my features i pushed to a branch be tested?

Answer: when you merge your implemented changes into the develop 
branch, they're automatically staged for the next testing cycle. Just 
like the current situation.

> I
> actually believe that despite the possible ease of development and
> contribution such a model actually leads to a unstable main branch or trunk.

I believe you need not to worry about this.

> I think testing should be a concern, and i would rather like to see a
> discussion about test improvements than VCS. However, if a different VCS
> means easier testing (for the test runners), I am all for it. I am
> curios to hear more about that!

I completely agree that testing is very important, and I also think 
that testing as an issue is mostly orthogonal to the branching model 
and the VCS. For as far as I can see git won't change much about the 
testing procedure, except that the volunteers might have less work to 
do on average (as observed by Julien).

IMO if the current testing model needs revision, it should get its own 
thread.

HTH,
-Julian