Re: [boost] [1.37.0] branches/release open for merges

From: Daryle Walker (darylew_at_[hidden])
Date: 2008-08-20 16:52:40

On Aug 20, 2008, at 1:31 PM, Beman Dawes wrote:
> Daryle Walker wrote:
>> On Aug 19, 2008, at 8:34 AM, Rene Rivera wrote:
>>> Gennaro Prota wrote:
>>>> Beman Dawes wrote:
>>>>> ****************************************************************** 
>>>>> **
>>>>> branches/release is open for merging all stable changes,  
>>>>> including bug fixes, and major
>>>>> upgrades to existing libraries. Breaking changes should be  
>>>>> coordinated with libraries
>>>>> affected. New libraries may be added with permission of a  
>>>>> release manager.
>>>>> ****************************************************************** 
>>>>> **
>>>> Hi Beman, Rene, Daniel,
>>>> I know I should already know this, but I was completely lost in  
>>>> the Wiki pages. Perhaps just the stifling heat we have here.  
>>>> Well, I made several changes related to dynamic_bitset, in  
>>>> trunk, and I thought they would be (now) in the release 1.37  
>>>> branch. They aren't. So, where does the release branch originate  
>>>> from?
>>>
>>> It's always from the previous release.
>> Is this a good thing?  Wouldn't this mean that the releases will  
>> diverge from the trunk, increasingly so after each release?  I  
>> feel that would be _very_ bad.  Is there some sort of merging  
>> going on between the trunk and release (in either direction, or  
>> both)?  We don't want fixes and new libraries on the trunk being  
>> missed for release.
>
> Right. That's why the release manager runs an "unmerged changes"  
> analysis later in the release cycle and pesters developers who  
> appear to have been lax about merging changes.

If the trunk is kept always release-ready, then the release manager  
can just dump every file in without asking.  It should work with only  
minor tweaks needed.

Also, should we have so many developers potentially messing around  
with the merging mechanics?  Maybe it'd be better to have a small  
group of people to the integration.  This is important when we switch  
the Subversion server and repository format to 1.5, since an update  
to svn-1.5's built-in merge control requires everyone to change their  
client access at the same time.

>> Shouldn't the final form of the release workspace be merged back  
>> into the trunk (and then the branch [but not tag] deleted), and  
>> the next version's workspace branched from the merged trunk?
>
> No. That's the "Wild West" system we used to use. It was a  
> nightmare to manage. The new system is much better since branches/ 
> release stays much more stable, allowing us to get releases out  
> quarterly.

1. The "always release-ready" trunk (ARR-trunk) philosophy counters  
this.
2. Someone in a sub-thread branched from this one noted that the  
management nightmare has moved from one person to all.  Instead of  
each developer updating his/her part of the trunk at their leisure or  
as needed, now _every_ developer has to do that AND be vigilant about  
the release branch, which is effectively a parallel trunk that  
constantly needs attention.  This is bad since we're volunteers that  
come and go and your suggestion requires everyone to be like the  
release manager.  The ARR-trunk method makes this unnecessary.

With a ARR-trunk, we just branch off the trunk, do the minimal  
testing and fixes that were missed, and ship it.  Since the fixes  
were supposed to be there, we can safely merge them back into the  
trunk, then kill the branch (after tagging it, of course).  A problem  
from the Wild West days was letting the release branch fester for  
months (or year) while authors tried to get it release ready because  
the libraries in the trunk it branched from weren't kept (near)  
release ready.  ARR-trunk developers can't do that because the  
release branch is too short-lived to be a crutch.  Always basing the  
next release branch from the previous version is like festering by  
piecemeal.

Another problem is that the build, documentation, and testing systems  
still fall apart when someone looks at them funny.  Fixing (or  
replacing) those, especially so the processes can be as automated as  
possible, and therefore making the test runners' job as turn-key as  
possible, will provide the quicker turnarounds needed for the ARR- 
trunk to work.

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com