Send from my mobile device
> Am 08.10.2013 um 09:10 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > 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...). Big +1 for using newer Java versions! > > 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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
