On Wed, Oct 16, 2013 at 5:14 PM, Mark Thomas <ma...@apache.org> wrote:
> On 16/10/2013 21:34, Christian Grobmeier wrote: > > On 14 Oct 2013, at 9:13, Mark Thomas wrote: > > > >> On 13/10/2013 23:59, sebb wrote: > >>> On 13 October 2013 20:47, Phil Steitz <phil.ste...@gmail.com> wrote: > >>>> On 10/13/13 8:09 AM, James Carman wrote: > >>>>> Well, it has been 72 hours, so let's tally up the votes. As I see it > >>>>> (counting votes on both lists): > >>>>> > >>>>> +1s > >>>>> James Carman > >>>>> Romain Manni-Bucau > >>>>> Matt Benson > >>>>> Benedikt Ritter > >>>>> Bruno Kinoshita > >>>>> Gary Gregory > >>>>> Luc Maisonobe > >>>>> Oliver Heger > >>>>> Christian Grobmeier > >>>>> Torsten Curdt > >>>>> > >>>>> -1s > >>>>> Mark Thomas > >>>>> Thomas Vandahl > >>>>> Damjan Jovanovic > >>>>> Gilles Sadowski > >>>>> Jorg Schaible > >>>>> > >>>>> +0.5 > >>>>> Olivier Lamy > >>>>> > >>>>> +0 > >>>>> Ralph Goers > >>>>> > >>>>> -0 > >>>>> Emmanuel Bourg > >>>>> > >>>>> The vote passes, so Apache Commons will be moving to Git for SCM. We > >>>>> should begin working on a plan. I propose we set up a wiki page for > >>>>> that. > >>>> > >>>> I protest. It is fine for some components to experiment, but if we > >>>> are going to force all to move, we really need consensus and that is > >>>> clearly not the case here. I did not vote as I frankly saw the VOTE > >>>> as premature. We should use VOTEs as a last resort, not a first > >>>> step or way to avoid getting to consensus on non-release issues. > >>> > >>> I agree entirely with Phil. > >>> > >>> I would have voted -1 earlier, but was off-line for a few days. > >>> This is a huge change, and should not be bulldozed through. > >> > >> I too challenge the assertion that there is consensus for this change. > >> > >> I also agree with Sebb's characterisation of this being "bulldozed > >> through". > > > > I disagree. > > > > We have discussed it, we had a vote. We have not voted to push a red > > button on friday > > and to work with git alone on saturday. This was a vote for a general > > decision and > > it is clear (or should be) that changes like that are not made in a > > single day. > > > > Now what are you folks expecting? A full-fleshed out plan how to move? I > > think we should > > first decide IF we move and that was was happening here. > > What I was expecting was decisions to be made on the basis of consensus. > > The vote was not for a trial with a single component nor was it for a > gradual move to git as components decided that they wanted to move. The > vote was for a very black and white proposal to move the entire of > Commons from svn to git. > > The vote did not get consensus - far from it with around a third of > those voting against the proposal. Therefore my objection was to the > statement in the vote result that "Apache Commons will be moving to Git > for SCM". > Why don't we side-step the consensus vs. majority and so on issue, and let whomever wants git propose to move one component and see how that goes? Gary > > > It was also pretty clear to start with a small step first and move a > > single component. > > If that would went wrong we could either go back without bigger loss or > > discuss what needs to be improved. > > That is not what was stated in the vote. If it had been, I would have > voted +1. I indicated as much when I voted. > > > We are not using experimental bleeding edge technology here. We just > > wanted to decide if we will follow the git path or not. > > > > I really can't see anything bulldozed here. > > The bulldozing was the statement "Apache Commons will be moving to Git > for SCM" when a significant proportion of the committers voted against > such a move. > > >> I have no objection to a switch to git for those components where there > >> is consensus to do so amongst the active developers. > >> > >> I continue to strongly recommend that a single component volunteers to > >> be the svn->git guinea pig for Commons and that we allow that component > >> to work out any issues that crop up before any mass switch starts. If > >> there are no issues, great. If there are issues, better to have to deal > >> with one set of them rather than 40+ sets. > > > > I have not understood it otherwise. > > Why did you start to believe we move all components at once? > > The text of the vote, the text of the vote result and the context in > which the vote was conducted. At no point did the James (who was driving > this issue) make any statement that suggested (to me at least) anything > other than a wholesale migration from svn to git. > > >> Further, if the consensus amongst the active developers on a component > >> is that they wish to stick to svn, I see no why that component should be > >> forced to switch to git. > > > > I had the idea too and support it. > > At this point I am unclear what support there is for what since folks > appear to have very different interpretations of exactly what was being > voted on. > > I think that there is consensus for a single component to trial the svn > to git migration to see how it goes. That approach certainly has my > support although I won't be volunteering any of the components I'm > working on - while I can see the advantages of git, the git mirrors give > me most of the advantages with none of the migration pain. I'm sure that > balance will change over time but personally I'm not there yet. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
