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:55:02 GMT
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

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