commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <benerit...@gmail.com>
Subject Re: [DISCUSS] Moving to Git...
Date Tue, 08 Oct 2013 07:18:41 GMT


Send from my mobile device

> Am 08.10.2013 um 09:10 schrieb Romain Manni-Bucau <rmannibucau@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 <grobmeier@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" <sjr@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 <james@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-unsubscribe@commons.apache.org>
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<dev-unsubscribe@commons.apache.org>
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
>> ---
>> http://www.grobmeier.de
>> @grobmeier
>> GPG: 0xA5CC90DB
>> 
>> 
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<dev-unsubscribe@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
>> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message