Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com.br;
  h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=GQy5F5gCGpghxXrf8yA5pFrLP3fl0OX74kD+x42i3PDgKrejfwfVSrXDoQ/XL68SM9ClYqQt/14fm1ILuqFJWBSCvoDu0WoHKeMjNrITTEs2KB5PmcK53vv/VWvot9nntXYBFn6W0igngip+4kX0ZXWQpVlCGfmDEb6y1svRM8k=;
References: 
 <CALznzY5qxu5xAg1HH+4hJkmfePKeT1_d_oTLfsLbX9b43j-qCQ@mail.gmail.com>
 <CA+3tv22ZqKb0_0uHvZLqvd62mAzGQN-YcyNt=rwnm4v_=zHjxA@mail.gmail.com>
 <CACLE=7P-2XZRt109Yv_LwZ0EYva-OLNjvGMSe46eWHtO7zWhMw@mail.gmail.com>
 <B7BB7A0B-1E75-4217-A405-276FCCBF285E@gmail.com>
 <CACLE=7ObiHzfUF_WWnEsrXb71KRRrtpEYEbhWufVmRtaTgwjVQ@mail.gmail.com>
 <860f733895018e915d3335ffcdf88ac7@smtp.spaceroots.org>
Message-ID: <1381231261.82238.YahooMailNeo@web140705.mail.bf1.yahoo.com>
Date: Tue, 8 Oct 2013 04:21:01 -0700 (PDT)
From: "Bruno P. Kinoshita" <brunodepaulak@yahoo.com.br>
Reply-To: "Bruno P. Kinoshita" <brunodepaulak@yahoo.com.br>
Subject: Re: [DISCUSS] Moving to Git...
To: Commons Developers List <dev@commons.apache.org>
In-Reply-To: <860f733895018e915d3335ffcdf88ac7@smtp.spaceroots.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

+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 :)=0A=0ABruno P. Ki=
noshita=0Ahttp://kinoshita.eti.br=0Ahttp://tupilabs.com=0A=0A=0A___________=
_____________________=0AFrom: luc <luc@spaceroots.org>=0ATo: dev@commons.ap=
ache.org =0ASent: Tuesday, October 8, 2013 5:02 AM=0ASubject: Re: [DISCUSS]=
 Moving to Git...=0A=0A=0AHi all,=0A=0ALe 2013-10-08 09:10, Romain Manni-Bu=
cau a =E9crit=A0:=0A> Never said the opposite but git or svn is not a quest=
ioin IMO, both are=0A> simple and usable today. I'm more attracted by featu=
res than the infra=0A> around a project.=0A=0AI don't fully agree. The infr=
a is also important (not more or less than =0Arules, just as important).=0A=
=0AIn order to answer more precisely to initial topic by James, I think =0A=
each components should have=0Atheir own repository. As per Apache workflow,=
 we could basically have =0Athe Apache hosted repository=0Aas the reference=
, and anybody can clone it and work as they want (Git is =0Adecentralized).=
=0A=0AWhen someone people who are not committers want to contribute, they =
=0Asimply can put a repo they own=0Asomewhere so it is publicly visible (Gi=
thub if they want or their own =0Aserver, whatever ...). Then=0Acommitters =
could review the code and decide to merge them in the =0Areference Apache r=
epository, either=0Athe full changes with history or cherry picking some pa=
rts, or even =0Areworking everything by cloning=0Athe proposal repo in thei=
r own local workspace, edit everything, then =0Acommit to the reference.=0A=
=0AThis would be *much* easier than attaching patches to JIRA.=0A=0AAlso mo=
ving a component from sandbox to proper to dormant would simply =0Aputting =
a flag somewhere=0Aon the web site or documentation, it needs not be enforc=
ed as a tree =0Astructure in the repositories=0Awith three categories and c=
omponents underneath. This was well suited =0Awith SVN since we mainly=0Aha=
ve a very big svn server (which serves all Apache projects), but does =0Ano=
t seem to fit well with git.=0A=0A=0AOh, and of course I am big +1 to switc=
h to git, and would be ready to =0Ahelp other people do the=0Amove if they =
want. I am using Git since a few years now and am really =0Ahappy with it.=
=0A=0Abest regards,=0ALuc=0A=0A> =0A> For me commons looks like a big sandb=
ox where rules are more important =0A> than=0A> features (btw maven is abou=
t the same today). From my understanding =0A> commons=0A> shouldn't be proj=
ects moving a lot but just following java versions=0A> (generic for j5, lam=
bda for j8 ...) or "trends" if new features are =0A> deduced=0A> from it (f=
luent APIs etc...).=0A> =0A> All the infra doesn't help as a user and only =
the user experience means=0A> something.=0A> =0A> Just my point of view...=
=0A> =0A> *Romain Manni-Bucau*=0A> *Twitter: @rmannibucau <https://twitter.=
com/rmannibucau>*=0A> *Blog: =0A> **http://rmannibucau.wordpress.com/*<http=
://rmannibucau.wordpress.com/>=0A> *LinkedIn: **http://fr.linkedin.com/in/r=
mannibucau*=0A> *Github: https://github.com/rmannibucau*=0A> =0A> =0A> =0A>=
 2013/10/8 Christian Grobmeier <grobmeier@gmail.com>=0A> =0A>> On 8 Oct 201=
3, at 6:53, Romain Manni-Bucau wrote:=0A>> =0A>>=A0 Hi=0A>>> =0A>>> Not sur=
e svn is the issue. What makes quality and which rules are=0A>>> mandatory=
=0A>>> is more important IMO.=0A>>> =0A>> =0A>> If you want to attract a ne=
w generation it is important. Would you=0A>> contribute to a CVS project?=
=0A>> I would if you need it urgently for work. But in my prime time I =0A>=
> simply=0A>> don't have an=0A>> interest to install an cvs client no matte=
r how cool the software is. =0A>> I=0A>> think a projects infrastructure=0A=
>> is first entry barrier for contributing.=0A>> =0A>> Personally I have le=
arned about git and it took me a while. I am not a=0A>> super-hero but I en=
joy it.=0A>> =0A>> Btw, Guava uses Git too:=0A>> https://code.google.com/p/=
**guava-libraries/source/**checkout<https://code.google.com/p/guava-librari=
es/source/checkout>=0A>> =0A>> =0A>> =0A>> =0A>>> Following oracle java ver=
sion (with a single one late - java 6 when =0A>>> java 7=0A>>> is the curre=
nt one) is one key i think.=0A>>> =0A>>> Another one would be to remove pro=
ject from main sources/proper when=0A>>> nobody=0A>>> needs work on it anym=
ore.=0A>>> =0A>>> Separating each projects too...what a noise on commons ca=
use of not=0A>>> following it + which link between csv and math -> consiste=
ncy? NB: no=0A>>> project is too small.=0A>>> Le 8 oct. 2013 04:15, "James =
Ring" <sjr@jdns.org> a =E9crit :=0A>>> =0A>>>=A0 Whatever workflow we came =
up with, if we moved to Git I'd like to =0A>>> see=0A>>>> Gerritt =0A>>>> (=
https://code.google.com/p/**gerrit/<https://code.google.com/p/gerrit/>)=0A>=
>>> used for code review.=0A>>>> =0A>>>> On Mon, Oct 7, 2013 at 7:10 PM, Ja=
mes Carman =0A>>>> <james@carmanconsulting.com=0A>>>> >=0A>>>> wrote:=0A>>>=
> =0A>>>>> All,=0A>>>>> =0A>>>>> If we did want to move to Git, we'd probab=
ly have to figure out how=0A>>>>> we'd manage our "workflow" (couldn't thin=
k of a better word).=A0 I=0A>>>>> suppose we'd have a separate repo for eac=
h component?=A0 What about=0A>>>>> proper vs. sandbox?=A0 How would we acco=
mmodate that paradigm?=A0 Has=0A>>>>> anyone else already gone through this=
 thought process?=A0 I must =0A>>>>> admit,=0A>>>>> my git fu isn't what it=
 should be.=0A>>>>> =0A>>>>> James=0A>>>>> =0A>>>>> -----------------------=
-------**------------------------------**=0A>>>>> ---------=0A>>>>> To unsu=
bscribe, e-mail: =0A>>>>> dev-unsubscribe@commons.**apache.org<dev-unsubscr=
ibe@commons.apache.org>=0A>>>>> For additional commands, e-mail: dev-help@c=
ommons.apache.org=0A>>>>> =0A>>>>> =0A>>>> ------------------------------**=
------------------------------**=0A>>>> ---------=0A>>>> To unsubscribe, e-=
mail: =0A>>>> dev-unsubscribe@commons.**apache.org<dev-unsubscribe@commons.=
apache.org>=0A>>>> For additional commands, e-mail: dev-help@commons.apache=
.org=0A>>>> =0A>>>> =0A>>>> =0A>> =0A>> ---=0A>> http://www.grobmeier.de=0A=
>> @grobmeier=0A>> GPG: 0xA5CC90DB=0A=0A>> =0A>> =0A>> --------------------=
----------**------------------------------**---------=0A>> To unsubscribe, =
e-mail: =0A>> dev-unsubscribe@commons.**apache.org<dev-unsubscribe@commons.=
apache.org>=0A>> For additional commands, e-mail: dev-help@commons.apache.o=
rg=0A>> =0A>> =0A=0A-------------------------------------------------------=
--------------=0ATo unsubscribe, e-mail: dev-unsubscribe@commons.apache.org=
=0AFor additional commands, e-mail: dev-help@commons.apache.org=A0

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