Re: [boost] [git] neglected aspects

Subject: Re: [boost] [git] neglected aspects
From: Julien Nitard (julien.nitard_at_[hidden])
Date: 2012-02-10 11:36:39

>>> 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.
>
> Good to hear that at least I didn't under-estimate it. :-)
> I guess the difference between a merge with manual exceptions and
> cherry picking is only gradual, but I strongly agree neither is ideal.

Thanks for the effort, but what you proposed is a perfectly valid SVN
workflow to me. There's nothing specific to git, besides the naming
conventions of the branches, if I had to draw one for SVN the result
would be the exact same with s/develop/trunk/ and s/master/tags/.

On the other hand, whether we use git or SVN, I agree that the current
model is not efficient. I think that trunk and release are redundant,
it should be just trunk (this is not recommended just by me, see the
wikipedia entry on continuous integration that I quoted earlier), with
tags for releases. Since trunk is automatically tested, I see no
reason to add an additional step before release that seemed to be
completely neglected by developers.

Removing that unecessary (IMHO) release branch may force people to pay
more attention to what they are commiting and lower the load on the
test system (which seems to be a problem) because there's no more
release to test. Instead, a temporary release branch may be created
from trunk and worked on directly when the beta is fixed. (And it
seems to be that this is exactly what you proposed on your git schema)

Julien