Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-Id: <0B93C8B9-FA63-4828-851E-18DC331FA9AB@apache.org>
From: Damien Katz <damien@apache.org>
To: dev@couchdb.apache.org
In-Reply-To: <e2111bbb0906011241m4f74177es6a145c6dd93a572e@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: changing branch commit merge block procedure
Date: Mon, 1 Jun 2009 15:55:59 -0400
References: <e282921e0906011200v5e51e6ccud582de66fe8c8988@mail.gmail.com>
 <DD32F45D-0317-42DB-8BA7-D7244C219E8E@apache.org>
 <e2111bbb0906011241m4f74177es6a145c6dd93a572e@mail.gmail.com>


On Jun 1, 2009, at 3:41 PM, Paul Davis wrote:

> On Mon, Jun 1, 2009 at 3:26 PM, Damien Katz <damien@apache.org> wrote:
>>
>> On Jun 1, 2009, at 3:00 PM, Chris Anderson wrote:
>>
>>> Devs,
>>>
>>> We've talked some about discontinuing use of svn's merge/block
>>> procedure for maintaining old release branches, in favor just asking
>>> committers to remember to put applicable patches into the 0.9.x
>>> branch.
>>
>> My experience is that by default, patches shouldn't be included in  
>> branches.
>> The point of branches is to provide a an increasingly stable code  
>> base, so
>> that users of the branch can get updates and upgrade with little  
>> fear the
>> update will introduce a change in behavior or regression into their
>> production systems.
>>
>> Therefore, only patches that fix serious bugs (data loss, hangs) or
>> regressions (features that worked in previous versions no longer  
>> work)
>> should be considered for merging. Any patch that is merged back  
>> should be
>> justifiable as to why it's important enough to risk destabilizing the
>> branch.
>>
>> I think idea that we need to track all the patches going into trunk  
>> and the
>> branches, because we might forget an important patch. Yes, we might  
>> forget
>> an important patch, but then we can simply apply to the next  
>> release of the
>> branch if its that important. Rather than track all the patches for  
>> all
>> branches, we should rely on the community to tells us what's an  
>> important
>> patch and what is not.
>>
>> -Damien
>>
>
> I'm in complete agreement with one caveat. I would imagine that the
> group of people that care about a maintenance branch, and the group
> that pays attention to the individual commits have a relatively small
> overlap. If there were some mechanism that we agreed on for getting
> public feed back on possible maintenance patches I'd be cool.

I think we should just ask the mailing list, "Are there any trunk  
fixes you want to see in 0.9.1?" a week before we release.

>
>
> The reason I tend to worry about this is that I seem to do alot of
> user facing patches that I kinda waffle on whether they should be
> maintenance or not. A prime example would be whether patches that
> improve error messages should go in or not. I can see good arguments
> for both sides. Even something like, "submit it to the user@ for an
> informal vote" before putting in maintenance would be good enough for
> me.
>

IMO, unless that patch fixes a serious bug, it shouldn't be merged  
back. There is no objective criteria for what's is serious enough for  
inclusion, but I think at the minimum we need one person who thinks  
it's serious enough for inclusion, and at least on contributor who  
familiar enough with the area to weigh the risks of regression with  
the patch. And while I don't want to institute such a rule just yet,  
once we hit 1.0, all patches to a stable branch should be reviewed by  
2 contributors.

-Damien


> Paul Davis
>
>>>
>>>
>>> There is discussion to be had about what patches are applicable to
>>> point release branches.
>>>
>>> Perspectives?
>>>
>>> Chris
>>>
>>> --
>>> Chris Anderson
>>> http://jchrisa.net
>>> http://couch.io
>>
>>