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 19:25:26 GMT
On Mon, Jun 1, 2009 at 3:14 PM, Chris Anderson <jchris@apache.org> wrote:
> On Mon, Jun 1, 2009 at 12:08 PM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
>> On Mon, Jun 1, 2009 at 3:00 PM, Chris Anderson <jchris@apache.org> 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.
>>>
>>> There is discussion to be had about what patches are applicable to
>>> point release branches.
>>>
>>> Perspectives?
>>>
>>
>> I've gotten into the habit of making the decision right away and
>> adding or blocking the commit. That said I could also go for a "decide
>> to release, post a list of commits, and the comiter is responsible for
>> his/her list" with community input as needed. I'd think that would
>> allow for greater community awareness on what is/isn't hitting the
>> maintenance branches instead of relying on a comitter's judgement
>> alone.
>>
>> That said, I'll do as I'm told. I ride trunk so the decision doesn't
>> really affect me personally beyond having lots of people yell at me if
>> some behavior change sneaks into a maintenance branch...
>>
>
> The point of dropping the bookkeeping is that it doesn't really matter
> and is just more work for developers. If something needs to go into
> the maintenance branches, the users of those maintenance branches will
> let us know. Developers should use their discretion backporting fixes,
> with the goal of making the least amount of changes possible, while
> still fixing crucial bugs.
>

It was my understanding that the original motivation was so that the
release manager didn't have to worry that there was an outstanding
commit that should've been merged. Not that it'd be his/her fault if
we said "make release && distribute" and something got missed. Not
having some sort of mechanism to see which commits should or shouldn't
be in the maintenance release seems like we'd be begging to miss
something.

That said, dropping the bookkeeping during development and doing
something like posting the list of commits on a wiki for a day or two
before a release so that people have a chance to comment on things
would be just as well.

I think the bottom line is to avoid saying "Oh hehe, we missed a
commit, want to roll another release? kthxbai" to the release manager.

>> Paul Davis
>>
>>> Chris
>>>
>>> --
>>> Chris Anderson
>>> http://jchrisa.net
>>> http://couch.io
>>>
>>
>
>
>
> --
> Chris Anderson
> http://jchrisa.net
> http://couch.io
>

Mime
View raw message