+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 <l...@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 <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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
