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