IMO (and it is just my opinion), all commons projects should eventually move to git. The problem is that commons is more a disjoint group of small, fairly unrelated projects than a true umbrella project. As such, it might make more sense for a few projects to move before moving everything.
I'd be surprised if anyone questions your motives in this. I certainly don't. So I don't think you need to justify starting a vote, even if it might be premature. As for standardization, my opinion is that projects should be as standard as possible. That said, I found when working on VFS that at the time it was the only multi-module project and stuff other projects were doing in the build simply didn't work. So some amount of flexibility is required. Ralph On Oct 13, 2013, at 2:30 PM, James Carman wrote: > On Sun, Oct 13, 2013 at 5:06 PM, Phil Steitz <phil.ste...@gmail.com> wrote: >> >> 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. >> > > I will concede that the VOTE may have been a bit premature, judging by > the type of resistance we have to this move. Although, in my defense, > there are other projects already successfully using Git and they are > alive-and-well, so I didn't think in a million years that the > opposition would be based on feasibility of git. SVN may be the most > widely used, but my understanding is Git is definitely the most > popular (meaning a lot of people on SVN wish they could switch to > Git). My intent was not to splinter or fracture the community. On > the contrary, I brought this up hoping to *grow* the community. Also, > most of the dissenting opinions were expressed after the VOTE was > started. The original discussion thread was open for three days > before the VOTE was started. > >> 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. >> > > Yeah, I don't know how I feel about this one, especially when it comes > to SCM. I agree that we may need to be a little more loosey-goosey > with our "rules" that are project-wide (I consider myself a closest to > a libertarian :). There have to be some things we stay consistent, > on, though. Otherwise, why are we all grouped together, then? If we > get too loose, then it makes it difficult for folks to jump in on > another component and help out if they get an urge (if one of my math > books falls of the shelf and hits me in the head and I get some > inspiration). > >> 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. >> > > It would be great if you want to lend us a hand with the test > component we're creating in git, to help us iron out the workflow. It > might be a bit cheaper than moving [math] and trying to figure out how > to do releases. Might be more fun, too, since we're starting "green > field" :) > > --------------------------------------------------------------------- > 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
