[DISCUSS] Moving to Git...

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] Moving to Git...

James Carman
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving to Git...

James Ring
Whatever workflow we came up with, if we moved to Git I'd like to see
Gerritt (https://code.google.com/p/gerrit/) used for code review.

On Mon, Oct 7, 2013 at 7:10 PM, James Carman <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving to Git...

Romain Manni-Bucau
Hi

Not sure svn is the issue. What makes quality and which rules are mandatory
is more important IMO.

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" <[hidden email]> 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/) used for code review.
>
> On Mon, Oct 7, 2013 at 7:10 PM, James Carman <[hidden email]>
> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving to Git...

James Ring
In my experience quality is greatly enhanced by code review. Whatever
we can do to have gerrit-style code review, let's do that IMO.

On Mon, Oct 7, 2013 at 9:53 PM, Romain Manni-Bucau
<[hidden email]> wrote:

> Hi
>
> Not sure svn is the issue. What makes quality and which rules are mandatory
> is more important IMO.
>
> 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" <[hidden email]> 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/) used for code review.
>>
>> On Mon, Oct 7, 2013 at 7:10 PM, James Carman <[hidden email]>
>> 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: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving to Git...

Romain Manni-Bucau
My point was just the quality is not the issue of commons so not the first
thing to do/move
Le 8 oct. 2013 07:05, "James Ring" <[hidden email]> a écrit :

> In my experience quality is greatly enhanced by code review. Whatever
> we can do to have gerrit-style code review, let's do that IMO.
>
> On Mon, Oct 7, 2013 at 9:53 PM, Romain Manni-Bucau
> <[hidden email]> wrote:
> > Hi
> >
> > Not sure svn is the issue. What makes quality and which rules are
> mandatory
> > is more important IMO.
> >
> > 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" <[hidden email]> 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/) used for code review.
> >>
> >> On Mon, Oct 7, 2013 at 7:10 PM, James Carman <
> [hidden email]>
> >> 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: [hidden email]
> >> > For additional commands, e-mail: [hidden email]
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving to Git...

Christian Grobmeier
In reply to this post by Romain Manni-Bucau
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


>
> 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" <[hidden email]> 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/) used for code review.
>>
>> On Mon, Oct 7, 2013 at 7:10 PM, James Carman
>> <[hidden email]>
>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving to Git...

Romain Manni-Bucau
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...).

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 <[hidden email]>

> 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" <[hidden email]> 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 <[hidden email]
>>> >
>>> 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<[hidden email]>
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>
> ---
> http://www.grobmeier.de
> @grobmeier
> GPG: 0xA5CC90DB
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**apache.org<[hidden email]>
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving to Git...

Benedikt Ritter-3


Send from my mobile device

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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving to Git...

Emmanuel Bourg-3
In reply to this post by James Carman
Le 08/10/2013 04:10, James Carman a écrit :

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

Regarding the sandbox vs proper issue, I don't think this distinction
should be materialized in the structure of the source repository (either
Git or SVN). It should just be a mention on the component web page (at
least for the sandbox components, something like a red banner at the top
explaining this is an experimental component).

This would simplify our processes:
- no separate ACLs to manage proper/sandbox permissions
- no need to move the sources in the repository upon promotion
- no need to modify the links on the site

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving to Git...

Luc Maisonobe-2
In reply to this post by Romain Manni-Bucau
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 <[hidden email]>
>
>> 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" <[hidden email]> 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
>>>> <[hidden email]
>>>> >
>>>> 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<[hidden email]>
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail:
>>>> dev-unsubscribe@commons.**apache.org<[hidden email]>
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>>
>> ---
>> http://www.grobmeier.de
>> @grobmeier
>> GPG: 0xA5CC90DB
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail:
>> dev-unsubscribe@commons.**apache.org<[hidden email]>
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving to Git...

Romain Manni-Bucau
2013/10/8 luc <[hidden email]>

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

the point is: how many projects are you contributing compared to the number
you use...a few in enterprise generally. So we shouldn't prevent users to
contribute (not my point at all) but we shouldn't see it as a first citizen
while the other things are not fixed. The usage and features are far more
important and what should be fixed right now IMO.
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving to Git...

Emmanuel Bourg-3
In reply to this post by Luc Maisonobe-2
Le 08/10/2013 10:02, luc a écrit :

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

There is an open issue though, when a contributor attaches a patch to
JIRA it leaves a proof that he allowed the ASF to include his code.
Merging directly from Github isn't enough from a legal standpoint.


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

+1, and I would even support that move if we stay with SVN.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving to Git...

Mark Thomas
On 08/10/2013 09:30, Emmanuel Bourg wrote:
> Le 08/10/2013 10:02, luc a écrit :
>
>> This would be *much* easier than attaching patches to JIRA.
>
> There is an open issue though, when a contributor attaches a patch to
> JIRA it leaves a proof that he allowed the ASF to include his code.
> Merging directly from Github isn't enough from a legal standpoint.

As long as there is an intention to contribute (a pull request, an
e-mail to the dev list, a comment on a Jira, etc.) then there is no issue.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving to Git...

Xavier Detant
In reply to this post by Romain Manni-Bucau
I think all your points are important but are not exclusive.

I totally agree with Romain, the usage and features are extremely important
and we should move on (following Java version, etc…) but the simpler
someone can contribute, the faster we'll go.

I think, as Luc said, that git is a big plus for that. Let's say you're a
lambda person, you just use commons for work and found a bug you need to
fix for your app. On svn, you'll fix it, use it in your app, but you will
not share it, may be not even with your colleagues since you'll have to
build up a svn server for your fork. It's obvious that in this condition,
you won't open a Jira and give a patch : it's not your work and it's too
long/boring. On git you'll share it easily with your colleagues and the
cost to give it back to the ASF is near to zero (it's just a link to it's
repo).

I think the real question is, how much does it cost to the current
commiters to move from svn to git ? And the answer is «not much» just the
time to create the repos and push the code to it and one hour or two to get
used to git.

Do we really want to loose more potential contributions because of a
resistance to change ?

I'm a +1 for git.



2013/10/8 Romain Manni-Bucau <[hidden email]>

> 2013/10/8 luc <[hidden email]>
>
> > 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).
> >
>
> the point is: how many projects are you contributing compared to the number
> you use...a few in enterprise generally. So we shouldn't prevent users to
> contribute (not my point at all) but we shouldn't see it as a first citizen
> while the other things are not fixed. The usage and features are far more
> important and what should be fixed right now IMO.
>



--
Xavier DETANT
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving to Git...

Romain Manni-Bucau
everybody seems ok for git, maybe time to throw a vote and go to next
topics ;)

*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 Xavier Detant <[hidden email]>

> I think all your points are important but are not exclusive.
>
> I totally agree with Romain, the usage and features are extremely important
> and we should move on (following Java version, etc…) but the simpler
> someone can contribute, the faster we'll go.
>
> I think, as Luc said, that git is a big plus for that. Let's say you're a
> lambda person, you just use commons for work and found a bug you need to
> fix for your app. On svn, you'll fix it, use it in your app, but you will
> not share it, may be not even with your colleagues since you'll have to
> build up a svn server for your fork. It's obvious that in this condition,
> you won't open a Jira and give a patch : it's not your work and it's too
> long/boring. On git you'll share it easily with your colleagues and the
> cost to give it back to the ASF is near to zero (it's just a link to it's
> repo).
>
> I think the real question is, how much does it cost to the current
> commiters to move from svn to git ? And the answer is «not much» just the
> time to create the repos and push the code to it and one hour or two to get
> used to git.
>
> Do we really want to loose more potential contributions because of a
> resistance to change ?
>
> I'm a +1 for git.
>
>
>
> 2013/10/8 Romain Manni-Bucau <[hidden email]>
>
> > 2013/10/8 luc <[hidden email]>
> >
> > > 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).
> > >
> >
> > the point is: how many projects are you contributing compared to the
> number
> > you use...a few in enterprise generally. So we shouldn't prevent users to
> > contribute (not my point at all) but we shouldn't see it as a first
> citizen
> > while the other things are not fixed. The usage and features are far more
> > important and what should be fixed right now IMO.
> >
>
>
>
> --
> Xavier DETANT
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving to Git...

Emmanuel Bourg-3
In reply to this post by Xavier Detant
Le 08/10/2013 10:38, Xavier Detant a écrit :

> I think, as Luc said, that git is a big plus for that. Let's say you're a
> lambda person, you just use commons for work and found a bug you need to
> fix for your app. On svn, you'll fix it, use it in your app, but you will
> not share it, may be not even with your colleagues since you'll have to
> build up a svn server for your fork. It's obvious that in this condition,
> you won't open a Jira and give a patch : it's not your work and it's too
> long/boring. On git you'll share it easily with your colleagues and the
> cost to give it back to the ASF is near to zero (it's just a link to it's
> repo).

I don't think using SVN is a barrier to private modifications like this.
People just fork the mirror on Github, or import the code with git-svn.

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving to Git...

Xavier Detant
2013/10/8 Emmanuel Bourg <[hidden email]>

>
> I don't think using SVN is a barrier to private modifications like this.
> People just fork the mirror on Github, or import the code with git-svn.
>
>
I didn't said it was. Of course you'll do your private change, but you
won't share it easily (not as easily as with git IMO).

--
Xavier DETANT
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving to Git...

Romain Manni-Bucau
just an habit. svn diff && attach diff to a jira is as easy/hard as git
push + PR.

If you want to push back your changes you'll do whatever the techno is.

*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 Xavier Detant <[hidden email]>

> 2013/10/8 Emmanuel Bourg <[hidden email]>
>
> >
> > I don't think using SVN is a barrier to private modifications like this.
> > People just fork the mirror on Github, or import the code with git-svn.
> >
> >
> I didn't said it was. Of course you'll do your private change, but you
> won't share it easily (not as easily as with git IMO).
>
> --
> Xavier DETANT
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving to Git...

Bruno P. Kinoshita
In reply to this post by Luc Maisonobe-2
+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 <[hidden email]>
To: [hidden email]
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 <[hidden email]>
>
>> 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" <[hidden email]> 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
>>>> <[hidden email]
>>>> >
>>>> 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<[hidden email]>
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>> To unsubscribe, e-mail:
>>>> dev-unsubscribe@commons.**apache.org<[hidden email]>
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>>
>>
>> ---
>> http://www.grobmeier.de
>> @grobmeier
>> GPG: 0xA5CC90DB

>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail:
>> dev-unsubscribe@commons.**apache.org<[hidden email]>
>> For additional commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email] 

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Moving to Git...

Christian Grobmeier
In reply to this post by Romain Manni-Bucau
On 8 Oct 2013, at 11:42, Romain Manni-Bucau wrote:

> just an habit. svn diff && attach diff to a jira is as easy/hard as
> git
> push + PR.

Tools like GitHub succeed because not everybody agrees with you.
svn/diff is stoneage to some. git/pr is the future for them. Maybe you
are right about the habit thing, but it doesn't change the fact
everybody seems to enjoy with git these days. SVN is on the same road as
CVS. It's not that I don't like SVN. It has served me well and I still
use it. I know teams which are doing better with SVN. But esp in open
source using SVN looks like the code is maintained by dinosaurs who
don't want to work with "new things".

Please note, I am not saying we should move on to Git right now.

Moving to Git will be a lot of work and we'll have a lot of questions to
answer.
For example: how would we deal with pull requests? There are no partial
checkouts in git. We would have most likely one repos per component.
Would we need to create a "super parent component" including all proper
components as submodule, like we have the svn view? And so on.

If we have enough willing folks to push this forward, I am happy to see
it happen (unfort i am tight of time at the moment)

Cheers


>
> If you want to push back your changes you'll do whatever the techno
> is.
>
> *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 Xavier Detant <[hidden email]>
>
>> 2013/10/8 Emmanuel Bourg <[hidden email]>
>>
>>>
>>> I don't think using SVN is a barrier to private modifications like
>>> this.
>>> People just fork the mirror on Github, or import the code with
>>> git-svn.
>>>
>>>
>> I didn't said it was. Of course you'll do your private change, but
>> you
>> won't share it easily (not as easily as with git IMO).
>>
>> --
>> Xavier DETANT
>>


---
http://www.grobmeier.de
@grobmeier
GPG: 0xA5CC90DB

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12