couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: Roadmap process and merge procedure
Date Wed, 17 Apr 2013 15:01:11 GMT
I'll let someone more familiar with Git, and the conversations we had
around this, answer.

To be honest, I am less interested in debating the specifics of the
proposal than I am about actually getting a proposal agreed upon, and
putting it into practice. We are a little over a week away from the next
bugfix release window, and a little over two months away from the next
feature release window.

I need someone to help me put this stuff into motion. We keep talking about
the new release process / merge procedure, but it's been almost a year now,
and nothing has happened. (And I am as much if not more so to blame for
that as anyone else.)

What would be great is if someone who was involved in fleshing out the
original proposal (Bob, Paul, Jan, etc) could lend a hand and pair up with
me for an evening to get all this put into motion.


On 17 April 2013 15:40, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:

> How does that impact master vs. 1.4.x?
>
> On Wed, Apr 17, 2013 at 4:36 PM, Noah Slater <nslater@apache.org> wrote:
> > The goal was that you only merge in features when they are ready, and
> come
> > with tests, and docs, and what have you. And that you actually call a
> lazy
> > consensus "merge request" on dev@ before you can merge in.
> >
> >
> >
> >
> > On 17 April 2013 15:18, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
> >
> >> On Wed, Apr 17, 2013 at 4:02 PM, Noah Slater <nslater@apache.org>
> wrote:
> >> > So that features can be merged into it as they become ready.
> >> >
> >> > Check out:
> >> >
> >> > http://wiki.apache.org/couchdb/Merge_Procedure
> >> >
> >> > Thoughts?
> >>
> >> Seems like you could call the next-feature-release branch "master",
> >> and not have to start a new branch every time.
> >>
> >> Cheers,
> >>
> >> Dirkjan
> >>
> >
> >
> >
> > --
> > NS
>



-- 
NS

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