commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruno P. Kinoshita" <brunodepau...@yahoo.com.br>
Subject Re: [DISCUSS] Moving to Git...
Date Tue, 08 Oct 2013 11:21:01 GMT
+1 to moving to git as well, and the workflow with a pull request + cherry picking or merging
by a committer sounds good to me too :)

Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com


________________________________
From: luc <luc@spaceroots.org>
To: dev@commons.apache.org 
Sent: Tuesday, October 8, 2013 5:02 AM
Subject: Re: [DISCUSS] Moving to Git...


Hi all,

Le 2013-10-08 09:10, Romain Manni-Bucau a écrit :
> 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.

I don't fully agree. The infra is also important (not more or less than 
rules, just as important).

In order to answer more precisely to initial topic by James, I think 
each components should have
their own repository. As per Apache workflow, we could basically have 
the Apache hosted repository
as the reference, and anybody can clone it and work as they want (Git is 
decentralized).

When someone people who are not committers want to contribute, they 
simply can put a repo they own
somewhere so it is publicly visible (Github if they want or their own 
server, whatever ...). Then
committers could review the code and decide to merge them in the 
reference Apache repository, either
the full changes with history or cherry picking some parts, or even 
reworking everything by cloning
the proposal repo in their own local workspace, edit everything, then 
commit to the reference.

This would be *much* easier than attaching patches to JIRA.

Also moving a component from sandbox to proper to dormant would simply 
putting a flag somewhere
on the web site or documentation, it needs not be enforced as a tree 
structure in the repositories
with three categories and components underneath. This was well suited 
with SVN since we mainly
have a very big svn server (which serves all Apache projects), but does 
not seem to fit well with git.


Oh, and of course I am big +1 to switch to git, and would be ready to 
help other people do the
move if they want. I am using Git since a few years now and am really 
happy with it.

best regards,
Luc

> 
> 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 <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 

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


Mime
View raw message