Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates
 209.85.160.54 as permitted sender)
Message-ID: <504A0ABA.7030604@gmail.com>
Date: Fri, 07 Sep 2012 08:54:50 -0600
From: Martin Sebor <msebor@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: dev@stdcxx.apache.org
CC: Liviu Nicoara <nikkoara@hates.ms>
Subject: Re: A question (or two) of procedure, etc.
References: <5048E63F.8090603@hates.ms> <wfsjav0zgx.fsf@gmail.com>
 <50496333.2080004@gmail.com> <5049DD36.40405@hates.ms>
In-Reply-To: <5049DD36.40405@hates.ms>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

We should remember that there are a number of Jira issues that
we fixed on 4.2.x but haven't merged out to 4.3.x or trunk. The
idea behind the current process (4.2.x -> 4.3.x -> trunk) was
to be able to simply merge the branches in bulk, as opposed to
an fix at a time. Unfortunately, we ran into some Subversion
issues that made it a huge pain. IIRC, Travis did it at least
once so he might still remember the details.

Before we change the process, it might be a good idea to go
through the Jira issues (I think they are resolved but not
Closed), commit the 4.2.x fixes to 4.3.x and trunk, and close
them. That way we won't have to wonder what fixes are where.

Going forward, to avoid this mess, I would suggest we make
an effort to commit fixes wherever necessary at the same
time instead of delaying it until some time in the future.

Martin

On 09/07/2012 05:40 AM, Liviu Nicoara wrote:
> On 09/06/12 23:00, Martin Sebor wrote:
>>> Every project has certain branch strategy, I'm not sure about this so
>>> maybe Martin can advice. I prefer to develop on trunk and cherry pick
>>> to the other branches avoiding bulk merges (and that's in both
>>> directions).
>>
>> We've done most work on 4.2.x for historical reasons. I think
>> a better strategy is to develop, as you suggest, on trunk which
>> has the least restrictive commit policy, and merge changes out
>> to the more restrictive branches as appropriate.
>
> If open to voting, I am for trunk first, branches later.
>
> Liviu