There's no veto notion here - if we're abiding by the lowest denominator of the base Apache voting rules, vetoes are only for code votes. While this is to do with code, it's not code itself.
I see it settled in that an understanding is reached. The majority of those voting have indicated that they have a preference for git over svn and would like Commons to move in that direction. I'm definitely confused by the proposal. Being selfish - what's this going to change? The discussion implied code review would be used (are we moving to RTC?). It implied that there would be issues in checking all of Commons out (which has always been very important to me, though I'll admit not right now as I've not been supporting cross-Commons features the way others, noticeably Sebb, are). If we break the ability for someone to fix issues across all components, we increase the likelihood that central changes won't be pushed out. Will GitHub pull requests get better? Because they're currently a mess. Will we lose existing contributors due to putting a hurdle in their way? Will the development workflow change? While I use git at the moment, I'm aware I use it in an svn way because I'm always hitting pains where git's support for my workflow involves doing odd items (acknowledging the issue is me for not developing in a git way). If we move a component to git, will I still be able to commit to it via some form of svn2git bridge, or will each partial migration mean a component vanishing from trunks-proper? Browsing the git discuss thread, it was surprisingly light on details. To be excited by this and not feel frustrated, I suspect I'll need more support (explanations before hand, answers to dumb questions). However this seems much like the moves to maven1 and maven2. A difference to the maven1/maven2 moves is that they were done with overlap. Components were not unusual to have Ant, Maven 1 and Maven 2 build systems. Summary: I won't add my vote because I don't understand the question. We're not voting on moving to Git, we're voting on something bigger and only those voting +1 know what that is :) I'm not against it, but I know there will be pain, someone else is going to do all the work [hey, I served my time on jira and svn] and I'll slowly catch up and hopefully not get lost along the way :) --- An aside: I'm not convinced btw that another thread entitled "[VOTE] Stay on Subversion" wouldn't also be passed. To conjecture culturally, those fastest to respond are most likely to want to move to Git, while those slower are most likely to want to stay on Subversion. Mobilization of the SVN vote would probably exceed the Git vote, however I believe there is a level of those interacting more often with the scm having a greater voice in the choice of system being interacted with. Hen On Wednesday, October 16, 2013, James Ring wrote: > So did any committer want to exercise a veto? Otherwise the matter is > settled right? > On Oct 16, 2013 6:38 PM, "sebb" <seb...@gmail.com> wrote: > > > On 17 October 2013 02:10, Ralph Goers <ralph.go...@dslextreme.com> > wrote: > > > > > > On Oct 16, 2013, at 2:46 PM, James Ring wrote: > > > > > >> Do Apache by-laws require a quorum? Was there a quorum for this vote? > > >> > > > > > > Apache voting rules are documented at > > http://www.apache.org/foundation/voting.html. However, that page doesn't > > define "consensus" which is where some of the disagreement came from. > > > > It's defined in the glossary: > > > > http://www.apache.org/foundation/glossary.html#ConsensusApproval > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > >
