couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: changing branch commit merge block procedure
Date Mon, 01 Jun 2009 19:41:39 GMT
On Mon, Jun 1, 2009 at 3:26 PM, Damien Katz <> 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.

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

Paul Davis

>> There is discussion to be had about what patches are applicable to
>> point release branches.
>> Perspectives?
>> Chris
>> --
>> Chris Anderson

View raw message