couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [REQUEST] [REMINDER] Merge changes for CouchDB 1.3.1
Date Wed, 22 May 2013 16:58:29 GMT
Erm, sorry, Tuesday. :)

(And to clarify, I'm pumped we're having this conversation, I just
wanna separate the threads!)


On 22 May 2013 17:55, Noah Slater <nslater@apache.org> wrote:

> Can we move the rest of this discussion over to the "[DISCUSS] Git
> workflow" please. :)
>
> The focus of this thread is: what do we need to do to make sure we can
> call a successful vote on Thursday?
>
>
> On 22 May 2013 17:38, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
>
>> On Wed, May 22, 2013 at 3:29 AM, Randall Leeds <randall.leeds@gmail.com>
>> wrote:
>> > On Tue, May 21, 2013 at 6:22 PM, Randall Leeds <randall.leeds@gmail.com>
>> wrote:
>> >> Here's a diagram. In this I show a feature branch landing on master
>> >> and a backport of it landing on 1.3.x, but if we follow the procedure
>> >> I'm suggesting I think it can even be easy to keep track of
>> >> cherry-picked backports.
>> >>
>> >> https://friendpaste.com/2AW98kyY8gQck6W1CjpZLY
>> >>
>> >> The fancy things here are
>> >>   * merge-base: to find the common ancestor
>>
>> As in, the common ancestor on a release branch? Because you don't want
>> to use the old feature branch head as ancestor, but rather the branch
>> point where the release branch deviated from master?
>>
>> >>   * --no-commit: so NEWS and CHANGES can be reconciled atomically with
>> >> respect to what the git logs will say is unmerged
>>
>> Not sure why you'd need that here.
>>
>> >>   * -Xours: so that we can merge release branches to master *without*
>> >> code changes, just to mark a point in history so that a future
>> >> merge-base will only show us what hasn't made it into NEWS and CHANGES
>> >> since we last did this.
>> >
>> > (snip)
>> >
>> > But maybe I'm overthinking it since one alternative is to just update
>> > NEWS and CHANGES whenever we make commits. However, I think if we just
>> > merge releases to master whenever we make a backport or a release then
>> > it will be a very quick and painless process to update NEWS and
>> > CHANGES when it comes time for 1.4.x.
>>
>> Yeah, I don't think we actually need the "ours" merge strategy here.
>>
>> I do think we should try merging from release branch to master some
>> time soon (e.g. after the next feature release).
>>
>> Cheers,
>>
>> Dirkjan
>>
>
>
>
> --
> NS
>



-- 
NS

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message