On 10/13/13 1:52 PM, James Carman wrote: > Phil, > > While I appreciate your concerns, the vote is a valid vote: > > "Votes on procedural issues follow the common format of majority rule > unless otherwise stated. That is, if there are more favourable votes > than unfavourable ones, the issue is considered to have passed -- > regardless of the number of votes in each category. (If the number of > votes seems too small to be representative of a community consensus, > the issue is typically not pursued. However, see the description of > lazy consensus for a modifying factor.)" > > I got this information from: > > http://www.apache.org/foundation/voting.html > > We definitely have enough people voting to be considered a consensus > (consensus != unanimous). > > However, we will not move forward with the Git move if we don't have > any luck with our test component (different thread). If we see the > test component isn't working out well, then we can just decide (or > vote again) to scrap the idea and move on. Hopefully that addresses > your concerns.
As I said, I am fine with experimenting and based on that experience seeing if we can actually get consensus. I stand by my statement above that the VOTE was premature and while "legal" from ASF perspective it is not a good practice to try to force consensus by VOTE-ing and conclude based on a mixed vote that consensus exists. Another healthy discussion that we need to have is how much standardization are we going to force on components. My view is less == better, which means the move to git does not have to be all at once or even ever done uniformly. Somewhat ironically, I am +1 for experimenting with git in [math] if Luc is willing to take the lead in setting it up and we can come to consensus among the active [math] committers that we think it is a good thing to spend time on. I just don't think its fair to those who happen to have missed the last couple of days or chose not to VOTE, or those who voted -1 to assume that we have "consensus" to move everything. Phil > > Thanks, > > James > > On Sun, Oct 13, 2013 at 3:47 PM, 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. >> >> Phil >>> Please let me know if I have missed anyone's vote. Having two vote >>> threads (my fault) caused a bit of confusion, but I think I got >>> everyone's vote. >>> >>> Thank you, >>> >>> James >>> >>> On Fri, Oct 11, 2013 at 4:01 PM, Benedikt Ritter <brit...@apache.org> wrote: >>>> 2013/10/11 Oliver Heger <oliver.he...@oliver-heger.de> >>>> >>>>> Am 11.10.2013 02:10, schrieb Phil Steitz: >>>>>>> On Oct 10, 2013, at 4:41 PM, Olivier Lamy <ol...@apache.org> wrote: >>>>>>> >>>>>>> Even I like git and use it daily, I will vote +0,5. >>>>>>> >>>>>>> Why other apache projects need to have their own commons-csv >>>>>>> repackaged release? why tomcat need to use a svn:external on dbcp >>>>>>> instead of a released version? why servicemix need to repackage all >>>>>>> commons jar to have proper osgi bundles? >>>>>>> >>>>>>> I simply believe moving to git won't fix those problems about the too >>>>>>> complicated release process which scare folks here to try releasing a >>>>>>> component!! >>>>>>> So no release happen at the end.... >>>>>>> >>>>>> I agree that the release process is certainly a problem; but the big >>>>> problem IMO is just too many components for too few really active >>>>> committers. Once we actually have something ready to release, we have >>>>> generally been able to fumble our way through the process. The problem is >>>>> getting there. >>>>>> I think the best thing we can do is focus on getting some things ready >>>>> for release. I will help on pool, DBCP, math. I won't rob Mark of the >>>>> oppty to rm pool2, but will help ;). All are welcome to join the fun >>>>> cleaning up the docs and other loose ends on that and then dbcp2. >>>>>> Who wants to step up to drive some other things to release? >>>>> I plan to prepare a release of BeanUtils soon. >>>>> >>>> Good to hear. There is a lot to do. I started generification a while back. >>>> If you like you can join #asfcommons and we can have a talk about BU. >>>> >>>> Benedikt >>>> >>>> >>>>> Oliver >>>>> >>>>>> Phil >>>>>>>> On 11 October 2013 01:50, James Carman <ja...@carmanconsulting.com> >>>>> wrote: >>>>>>>> All, >>>>>>>> >>>>>>>> We have had some great discussions about moving our SCM to Git. I >>>>>>>> think it's time to put it to a vote. So, here we go: >>>>>>>> >>>>>>>> +1 - yes, move to Git >>>>>>>> -1 - no, do not move to Git >>>>>>>> >>>>>>>> The vote will be left open for 72 hours. Go! >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>>> -- >>>>>>> Olivier Lamy >>>>>>> Ecetera: http://ecetera.com.au >>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: 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 >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>> -- >>>> http://people.apache.org/~britter/ >>>> http://www.systemoutprintln.de/ >>>> http://twitter.com/BenediktRitter >>>> http://github.com/britter >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: 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 >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: 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
