Never said the opposite but git or svn is not a questioin IMO, both are simple and usable today. I'm more attracted by features than the infra around a project.
For me commons looks like a big sandbox where rules are more important than features (btw maven is about the same today). From my understanding commons shouldn't be projects moving a lot but just following java versions (generic for j5, lambda for j8 ...) or "trends" if new features are deduced from it (fluent APIs etc...). All the infra doesn't help as a user and only the user experience means something. Just my point of view... *Romain Manni-Bucau* *Twitter: @rmannibucau <https://twitter.com/rmannibucau>* *Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau* *Github: https://github.com/rmannibucau* 2013/10/8 Christian Grobmeier <grobme...@gmail.com> > On 8 Oct 2013, at 6:53, Romain Manni-Bucau wrote: > > Hi >> >> Not sure svn is the issue. What makes quality and which rules are >> mandatory >> is more important IMO. >> > > If you want to attract a new generation it is important. Would you > contribute to a CVS project? > I would if you need it urgently for work. But in my prime time I simply > don't have an > interest to install an cvs client no matter how cool the software is. I > think a projects infrastructure > is first entry barrier for contributing. > > Personally I have learned about git and it took me a while. I am not a > super-hero but I enjoy it. > > Btw, Guava uses Git too: > https://code.google.com/p/**guava-libraries/source/**checkout<https://code.google.com/p/guava-libraries/source/checkout> > > > > >> Following oracle java version (with a single one late - java 6 when java 7 >> is the current one) is one key i think. >> >> Another one would be to remove project from main sources/proper when >> nobody >> needs work on it anymore. >> >> Separating each projects too...what a noise on commons cause of not >> following it + which link between csv and math -> consistency? NB: no >> project is too small. >> Le 8 oct. 2013 04:15, "James Ring" <s...@jdns.org> a écrit : >> >> Whatever workflow we came up with, if we moved to Git I'd like to see >>> Gerritt >>> (https://code.google.com/p/**gerrit/<https://code.google.com/p/gerrit/>) >>> used for code review. >>> >>> On Mon, Oct 7, 2013 at 7:10 PM, James Carman <ja...@carmanconsulting.com >>> > >>> wrote: >>> >>>> All, >>>> >>>> If we did want to move to Git, we'd probably have to figure out how >>>> we'd manage our "workflow" (couldn't think of a better word). I >>>> suppose we'd have a separate repo for each component? What about >>>> proper vs. sandbox? How would we accommodate that paradigm? Has >>>> anyone else already gone through this thought process? I must admit, >>>> my git fu isn't what it should be. >>>> >>>> James >>>> >>>> ------------------------------**------------------------------** >>>> --------- >>>> 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 >>> >>> >>> > > --- > http://www.grobmeier.de > @grobmeier > GPG: 0xA5CC90DB > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> > For additional commands, e-mail: dev-h...@commons.apache.org > >
