Hi Hen, Send from my mobile device
> Am 17.10.2013 um 08:24 schrieb Henri Yandell <flame...@gmail.com>: > > Wooo! I won on my first post, and by being on the fence. Be afraid when I > have a strong opinion, be wery, wery afraid :) Not allowed to drink though. > > Hacking along tonight, I'm reminded of one reason why I would like to try > Git in Commons. It's the only place I tend to be working on parallel issues > at the same time and I would like to stash (if that's the right verb) a > patch that's part ready but waiting on feedback online. I started to deploy > the site with reports based on the uncommitted code and had to abort and > restart. With git you can stash changes AND work in local branches (or push local branches with history to your remote). Stashing is btw supported by some IDE without SCM at all (I think idea can do it). Nevertheless I agree with you, that this is a big + for git. I'd say we push out lang 3.2 and use lang as a test project, if all of lang's developers can agree on this. Benedikt > > Hen > > >> On Wed, Oct 16, 2013 at 9:39 PM, Dave Brosius <dbros...@apache.org> wrote: >> >> Those who wanted to move to Git have given up several days ago, leaving >> this thread to be 'argued' by >> those who successfully squashed the action. James has already canceled the >> test project request in INFRA, and >> so it seems pointless for this thread to continue. You won, go off and >> have a beer, and enjoy. >> >> >>> On 10/16/2013 11:56 PM, Henri Yandell 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 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<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<http://www.apache.org/foundation/glossary.html#ConsensusApproval> >>>>> >>>>> ------------------------------**------------------------------** >>>>> --------- >>>>> To unsubscribe, e-mail: >>>>> dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
