commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [VOTE] Move Apache Commons to Git for SCM...
Date Sun, 13 Oct 2013 22:16:47 GMT
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.


On Oct 13, 2013, at 2:30 PM, James Carman wrote:

> On Sun, Oct 13, 2013 at 5:06 PM, Phil Steitz <> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message