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] Update on using git
Date Wed, 05 Jun 2013 08:57:11 GMT
Awesome news. Thanks Randall!


On 5 June 2013 02:37, Randall Leeds <randall.leeds@gmail.com> wrote:

> I'll drive this. Let me try to wrangle a draft proposal together.
> Dirkjan replied to me and that feedback is helpful.
>
> On Tue, Jun 4, 2013 at 2:55 PM, Noah Slater <nslater@apache.org> wrote:
> > Note: I don't mean to put this on Bob. Anyone could drive this. But I do
> > think it needs a driver. Bob, Randall, and Dirkjan all seem to have the
> > most detailed thoughts on the subject, so I suggest one you might be in
> the
> > best position.
> >
> > And to clarify: someone disagreeing with you isn't a blocker. We're
> aiming
> > for discussion-lead decision-making. Feel free to supply the
> > "decision-making" that compliments the "discussion-lead" part. ;)
> >
> >
> > On 4 June 2013 22:36, Noah Slater <nslater@apache.org> wrote:
> >
> >> Odd way to phrase it. Alternative proposals should not be
> >> a destructive part of the process. The goal here is to generate ideas,
> toss
> >> out the ones that don't work, pick your favourite, and drive consensus
> on
> >> it.
> >>
> >> So, there are two possible ways I can see this unfolding:
> >>
> >>  * Everyone agrees with you that the git-flow stuff is not needed, in
> >> which case, great. Work everyone's comments in to the original proposal,
> >> and then move it from DISCUSS to VOTE.
> >>
> >>  * There is still some disagreement about what we want to do. In this
> >> case, I agree, we do not have consensus. (I wouldn't describe this as
> >> a destruction of coherency. Instead: productive discussion!) The next
> >> step forward in this instances is to drive that discussion, and
> hopefully
> >> come out with a proposal that most people like.
> >>
> >> I note that Randal posted several mails, and so did Dirkjan. But nobody
> >> has responded to them. A good way to kick this off again would be to
> >> respond to those points, I think.
> >>
> >> I would love to drive this, but I can't, mostly because I have no idea
> >> what I'm talking about when it comes to Git. ;)
> >>
> >>
> >> On 4 June 2013 19:03, Robert Newson <rnewson@apache.org> wrote:
> >>
> >>> Heh, if I felt I could conclude that thread I would have done so
> >>> already. We had a reasonably well described approach at one point and
> >>> coherency was destroyed by a late appearance of the git-flow
> >>> alternative.
> >>>
> >>> B.
> >>>
> >>>
> >>> On 4 June 2013 18:43, Noah Slater <nslater@apache.org> wrote:
> >>> > This thread is concluded. :) I meant the "[DISCUSS] Git workflow"
> >>> thread.
> >>> >
> >>> >
> >>> > On 4 June 2013 18:41, Robert Newson <rnewson@apache.org> wrote:
> >>> >
> >>> >> What's not concluded in this thread?
> >>> >>
> >>> >> B.
> >>> >>
> >>> >>
> >>> >> On 4 June 2013 18:04, Noah Slater <nslater@apache.org> wrote:
> >>> >> > Bob, are you able to help drive the Git thread to conclusion?
We
> >>> need to
> >>> >> > clarify this and document it. Think a lot people are confused
> right
> >>> now
> >>> >> > since it seems everything is in the air.
> >>> >> >
> >>> >> >
> >>> >> > On 31 May 2013 16:51, Robert Newson <rnewson@apache.org>
wrote:
> >>> >> >
> >>> >> >> master, as usual, and the x.y.z branches (for backports).
All
> other
> >>> >> >> branches should be feature or fix branches we've not deleted.
> >>> >> >>
> >>> >> >> B.
> >>> >> >>
> >>> >> >> On 31 May 2013 16:47, Wendall Cada <wendallc@apache.org>
wrote:
> >>> >> >> > I'm fairly well versed in using git and different
workflows,
> >>> rebase,
> >>> >> etc.
> >>> >> >> > However, I'm utterly confused as to how I might contribute
> >>> changes to
> >>> >> >> > couchdb, what branches are relevant, etc. Is there
> documentation
> >>> for
> >>> >> >> this,
> >>> >> >> > or a clear summary of decisions made?
> >>> >> >> >
> >>> >> >> > Thanks,
> >>> >> >> >
> >>> >> >> > Wendall
> >>> >> >>
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> > --
> >>> >> > NS
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > NS
> >>>
> >>
> >>
> >>
> >> --
> >> NS
> >>
> >
> >
> >
> > --
> > NS
>



-- 
NS

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