incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: changing branch commit merge block procedure
Date Mon, 01 Jun 2009 20:01:15 GMT
On Mon, Jun 1, 2009 at 3:55 PM, Damien Katz <damien@apache.org> wrote:
>
> 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.
>

Good enough for me. It occurs to me that if someone in the community
cares, then they'll have to exert some amount of effort in voicing
their opinion on getting something backported.

>>
>>
>> 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
>>>
>>>
>
>

Mime
View raw message