Subject: Re: [boost] [git] neglected aspects
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2012-02-10 12:25:15
On 02/10/2012 04:31 PM, Daniel James wrote:
> On 10 February 2012 15:01, Julian Gonggrijp<j.gonggrijp_at_[hidden]>
>> Note (1): my depiction of the current Boost workflow might be
>> inaccurate. If you see a way to improve the image, please go ahead
>> or let me know what needs to be changed.
> You've actually over-estimated our process. We never do a complete
> merge from trunk to release, just either cherry-pick changes, or do a
> sub-tree merge. There are often long neglected changes in trunk -
> which is a major problem with the current system.
>> Note (3): while this image helps to explain my point in , it
>> turns out from  that I didn't actually address Daniel James'
>> point. I'll return to the testing issue in a new reply to .
> 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
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. 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? 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 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!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk