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 <[email protected]> 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 <[email protected]> wrote: > > This thread is concluded. :) I meant the "[DISCUSS] Git workflow" thread. > > > > > > On 4 June 2013 18:41, Robert Newson <[email protected]> wrote: > > > >> What's not concluded in this thread? > >> > >> B. > >> > >> > >> On 4 June 2013 18:04, Noah Slater <[email protected]> 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 <[email protected]> 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 <[email protected]> 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
