On Wed, Oct 16, 2013 at 11:56 PM, Henri Yandell <flame...@gmail.com> wrote:
> 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 best thing to change for me will be: - I'll pay attention to Git pull requests. Right now, I do not because I cannot simply download a patch from JIRA and use my IDE to apply it. I just do not want to be bothered with reformatting the pull request or fiddling with the git command line (or GitHub site) until I get git to create a diff file SVN will digest. - I'll be able to stash work in progress to address for urgent tasks. No more creating a patch, saving it some place, getting a clean sandbox, applying another patch and so on. The other stuff will be the same but done differently (Maven magic, day-to-day commits). Gary > 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 > > > > > > > > > > > -- 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
