You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Hans Bakker <ma...@antwebsystems.com> on 2015/04/20 06:38:29 UTC
move to git.
As discussed at apachecon in Austin, i propose to switch from svn to git
for the ofbiz repository. The main reason being that all major
contributors are using git and contributions are cumbersome, further,
git allows for better branching and merging.
Regards,
Hans
Re: move to git.
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Hans,
I whole heartedly agree. I was totally (still am) amazed by the countless
features and speed of this version control system. Furthermore it would
make my contributions a lot faster because of its distributed nature where
I can easily branch out locally.
One more benefit would be the ability to adopt a more powerful branching
model such as http://nvie.com/posts/a-successful-git-branching-model/
Taher Alkhateeb
On Apr 20, 2015 7:39 AM, "Hans Bakker" <ma...@antwebsystems.com>
wrote:
> As discussed at apachecon in Austin, i propose to switch from svn to git
> for the ofbiz repository. The main reason being that all major contributors
> are using git and contributions are cumbersome, further, git allows for
> better branching and merging.
>
> Regards,
> Hans
>
Re: Vote: move to git.
Posted by Nicolas Malin <ni...@nereide.fr>.
-0 (maybe it's the same that +0 ;) ), I vote +0 when I will use git,
but currently the fthe fear of change :).
Le 05/05/2015 05:01, Hans Bakker a écrit :
> As the discussions seem to end, can i propose a vote?
>
> The question : should we convert the master SVN repository of Apache
> OFBIz to a GIT version?
> The possible answers are according the apache voting guidelines at:
> https://www.apache.org/foundation/voting.html
>
> *
>
> +1: 'Yes lets do it'
>
> * +0: 'I don't feel strongly about it, but I'm okay with this.'
> *
>
> -0.5: 'I don't like this idea, but I can't find any rational
> justification for my feelings.'
>
> *
>
> ++1: 'Wow! I like this! Let's /do/ it!'
>
> *
>
> -0.9: 'I /really/ don't like this, but I'm not going to stand in the
> way if everyone else wants to go ahead with it.'
>
> *
>
> +0.9: 'This is a cool idea and i like it, but I don't have time/the
> skills necessary to help out.'
>
> * -1 'I do not want this.'
>
>
> Votes will be possible for one week from today.
>
> Regards,
> Hans
>
> On 20/04/15 11:38, Hans Bakker wrote:
>> As discussed at apachecon in Austin, i propose to switch from svn to
>> git for the ofbiz repository. The main reason being that all major
>> contributors are using git and contributions are cumbersome, further,
>> git allows for better branching and merging.
>>
>> Regards,
>> Hans
>
Re: Vote: move to git.
Posted by Christian Geisert <ch...@isu-gmbh.de>.
Am 05.05.2015 05:01, schrieb Hans Bakker:
> As the discussions seem to end, can i propose a vote?
+0
I personally prefer git anytime over svn, but it seems a few people are
not comfortable with git (yet). I'm using it already with ofbiz locally
(no commit via git yet but will try it soon)
Christian
Re: Vote: move to git.
Posted by Martin Becker <ma...@ecomify.de>.
Full ack for Adams remarks.
There should be a +0.5 like „I like this idea, but the realization has to be well planned for a point in the future where the all over organization fits the needs for a different contribution process" ;-)
So, +0.5 from me.
Martin Becker
ecomify GmbH
www.ecomify.de
> Am 05.05.2015 um 06:25 schrieb Adam Heath <do...@brainfood.com>:
>
> This may be the nail in the coffin, at least for now, but +0, needs more discussion/planning. I've been using git-svn for longer than most with ofbiz, and would really love it if we were already using git, but it's just too soon.
>
> Just because git is decentralized, doesn't mean that there is no longer a center. *Someone* has to be pulling/merging all the branches, and who would step up to that plate? Who would want to take on the mantel? I don't think we as a community are ready to require that of someone.
>
> Of course, we need to start planning for this eventuality, imho, but we are still a long ways off.
>
> ps: I, and others, will continue to use git in our upstream svn interactions, as that seems to work well enough
>
> pps: as per Adrian's vote call, there is nothing actionable here.
>
> On 05/04/2015 10:01 PM, Hans Bakker wrote:
>> As the discussions seem to end, can i propose a vote?
>>
>> The question : should we convert the master SVN repository of Apache OFBIz to a GIT version?
>> The possible answers are according the apache voting guidelines at: https://www.apache.org/foundation/voting.html
>>
>> *
>>
>> +1: 'Yes lets do it'
>>
>> * +0: 'I don't feel strongly about it, but I'm okay with this.'
>> *
>>
>> -0.5: 'I don't like this idea, but I can't find any rational
>> justification for my feelings.'
>>
>> *
>>
>> ++1: 'Wow! I like this! Let's /do/ it!'
>>
>> *
>>
>> -0.9: 'I /really/ don't like this, but I'm not going to stand in the
>> way if everyone else wants to go ahead with it.'
>>
>> *
>>
>> +0.9: 'This is a cool idea and i like it, but I don't have time/the
>> skills necessary to help out.'
>>
>> * -1 'I do not want this.'
>>
>>
>> Votes will be possible for one week from today.
>>
>> Regards,
>> Hans
>>
>> On 20/04/15 11:38, Hans Bakker wrote:
>>> As discussed at apachecon in Austin, i propose to switch from svn to git for the ofbiz repository. The main reason being that all major contributors are using git and contributions are cumbersome, further, git allows for better branching and merging.
>>>
>>> Regards,
>>> Hans
>>
>
Re: Vote: move to git.
Posted by Adam Heath <do...@brainfood.com>.
This may be the nail in the coffin, at least for now, but +0, needs more
discussion/planning. I've been using git-svn for longer than most with
ofbiz, and would really love it if we were already using git, but it's
just too soon.
Just because git is decentralized, doesn't mean that there is no longer
a center. *Someone* has to be pulling/merging all the branches, and who
would step up to that plate? Who would want to take on the mantel? I
don't think we as a community are ready to require that of someone.
Of course, we need to start planning for this eventuality, imho, but we
are still a long ways off.
ps: I, and others, will continue to use git in our upstream svn
interactions, as that seems to work well enough
pps: as per Adrian's vote call, there is nothing actionable here.
On 05/04/2015 10:01 PM, Hans Bakker wrote:
> As the discussions seem to end, can i propose a vote?
>
> The question : should we convert the master SVN repository of Apache
> OFBIz to a GIT version?
> The possible answers are according the apache voting guidelines at:
> https://www.apache.org/foundation/voting.html
>
> *
>
> +1: 'Yes lets do it'
>
> * +0: 'I don't feel strongly about it, but I'm okay with this.'
> *
>
> -0.5: 'I don't like this idea, but I can't find any rational
> justification for my feelings.'
>
> *
>
> ++1: 'Wow! I like this! Let's /do/ it!'
>
> *
>
> -0.9: 'I /really/ don't like this, but I'm not going to stand in the
> way if everyone else wants to go ahead with it.'
>
> *
>
> +0.9: 'This is a cool idea and i like it, but I don't have time/the
> skills necessary to help out.'
>
> * -1 'I do not want this.'
>
>
> Votes will be possible for one week from today.
>
> Regards,
> Hans
>
> On 20/04/15 11:38, Hans Bakker wrote:
>> As discussed at apachecon in Austin, i propose to switch from svn to
>> git for the ofbiz repository. The main reason being that all major
>> contributors are using git and contributions are cumbersome, further,
>> git allows for better branching and merging.
>>
>> Regards,
>> Hans
>
Re: Vote: move to git.
Posted by Julien NICOLAS <ju...@nomaka.fr>.
+0.9
Julien.
Le 05/05/2015 05:01, Hans Bakker a écrit :
> As the discussions seem to end, can i propose a vote?
>
> The question : should we convert the master SVN repository of Apache
> OFBIz to a GIT version?
> The possible answers are according the apache voting guidelines at:
> https://www.apache.org/foundation/voting.html
>
> *
>
> +1: 'Yes lets do it'
>
> * +0: 'I don't feel strongly about it, but I'm okay with this.'
> *
>
> -0.5: 'I don't like this idea, but I can't find any rational
> justification for my feelings.'
>
> *
>
> ++1: 'Wow! I like this! Let's /do/ it!'
>
> *
>
> -0.9: 'I /really/ don't like this, but I'm not going to stand in the
> way if everyone else wants to go ahead with it.'
>
> *
>
> +0.9: 'This is a cool idea and i like it, but I don't have time/the
> skills necessary to help out.'
>
> * -1 'I do not want this.'
>
>
> Votes will be possible for one week from today.
>
> Regards,
> Hans
>
> On 20/04/15 11:38, Hans Bakker wrote:
>> As discussed at apachecon in Austin, i propose to switch from svn to
>> git for the ofbiz repository. The main reason being that all major
>> contributors are using git and contributions are cumbersome, further,
>> git allows for better branching and merging.
>>
>> Regards,
>> Hans
>
Re: Result: Vote: move to git.
Posted by Hans Bakker <h....@antwebsystems.com>.
That was a translation of your feeling :-)
On 12/05/15 14:51, Jacques Le Roux wrote:
> I guess it's a matter of feeling, I did not even vote and got a -0.9 :)
>
> Jacques
>
> Le 12/05/2015 08:59, Nicolas Malin a écrit :
>> Le 12/05/2015 03:19, Hans Bakker a écrit :
>>>
>>> Nicolas -0.9
>> :) I voted -0 Hans not -0.9 it's not the same ;)
>>
Re: Result: Vote: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
I guess it's a matter of feeling, I did not even vote and got a -0.9 :)
Jacques
Le 12/05/2015 08:59, Nicolas Malin a écrit :
> Le 12/05/2015 03:19, Hans Bakker a écrit :
>>
>> Nicolas -0.9
> :) I voted -0 Hans not -0.9 it's not the same ;)
>
Re: Result: Vote: move to git.
Posted by Nicolas Malin <ni...@nereide.fr>.
Le 12/05/2015 03:19, Hans Bakker a écrit :
>
> Nicolas -0.9
:) I voted -0 Hans not -0.9 it's not the same ;)
Re: Result: Vote: move to git.
Posted by Hans Bakker <h....@antwebsystems.com>.
Good suggestions, Michael
On 12/05/15 15:06, Michael Brohl wrote:
> Thanks Hans for taking the effort, but...
>
> - I see a Nicolas 3 times? I know of Julien Nicolas and Nicolas Mailin...
> - Martin Becker's vote is missing (ok, he introduced a new value,
> maybe it does not count)
>
> The last votes were a little bit confusing and are at least hard to
> follow. Maybe we should change the process a little bit, e.g.
>
> - only give a vote as direct answer to the vote call, in the first
> line of the answer
> - open a corresponding vote discussion thread where all the
> explanations and discussions take place
>
> Regards,
>
> Michael Brohl
> ecomify GmbH
> www.ecomify.de
>
> Am 12.05.15 um 03:19 schrieb Hans Bakker:
>> Thank you for the interst and 126 messages on this subject.
>>
>> Looks like we do not want to go with the technological developments yet.
>>
>> Thank you all for your time.
>>
>> The result of the vote if we should move to git:
>>
>> Binding:
>> Jacques -0.9
>> Nicolas -0.9
>> Jacopo -1
>> Adam +0
>> Scott +0
>> Nicolas +0
>>
>> Non Binding:
>> Adrian +0
>> Taher Alkhateeb: +1
>> Christian Carlow +1
>> Pierre +0
>> michael.brohl +0
>> Christian +0
>> Gil portenseigne +0
>> Nicolas +0.9
>>
>> On 05/05/15 10:01, Hans Bakker wrote:
>>> As the discussions seem to end, can i propose a vote?
>>>
>>> The question : should we convert the master SVN repository of Apache
>>> OFBIz to a GIT version?
>>> The possible answers are according the apache voting guidelines at:
>>> https://www.apache.org/foundation/voting.html
>>>
>>> *
>>>
>>> +1: 'Yes lets do it'
>>>
>>> * +0: 'I don't feel strongly about it, but I'm okay with this.'
>>> *
>>>
>>> -0.5: 'I don't like this idea, but I can't find any rational
>>> justification for my feelings.'
>>>
>>> *
>>>
>>> ++1: 'Wow! I like this! Let's /do/ it!'
>>>
>>> *
>>>
>>> -0.9: 'I /really/ don't like this, but I'm not going to stand in the
>>> way if everyone else wants to go ahead with it.'
>>>
>>> *
>>>
>>> +0.9: 'This is a cool idea and i like it, but I don't have time/the
>>> skills necessary to help out.'
>>>
>>> * -1 'I do not want this.'
>>>
>>>
>>> Votes will be possible for one week from today.
>>>
>>> Regards,
>>> Hans
>>>
>>> On 20/04/15 11:38, Hans Bakker wrote:
>>>> As discussed at apachecon in Austin, i propose to switch from svn
>>>> to git for the ofbiz repository. The main reason being that all
>>>> major contributors are using git and contributions are cumbersome,
>>>> further, git allows for better branching and merging.
>>>>
>>>> Regards,
>>>> Hans
>>>
>
>
Re: Result: Vote: move to git.
Posted by Michael Brohl <mi...@ecomify.de>.
Thanks Hans for taking the effort, but...
- I see a Nicolas 3 times? I know of Julien Nicolas and Nicolas Mailin...
- Martin Becker's vote is missing (ok, he introduced a new value, maybe
it does not count)
The last votes were a little bit confusing and are at least hard to
follow. Maybe we should change the process a little bit, e.g.
- only give a vote as direct answer to the vote call, in the first line
of the answer
- open a corresponding vote discussion thread where all the explanations
and discussions take place
Regards,
Michael Brohl
ecomify GmbH
www.ecomify.de
Am 12.05.15 um 03:19 schrieb Hans Bakker:
> Thank you for the interst and 126 messages on this subject.
>
> Looks like we do not want to go with the technological developments yet.
>
> Thank you all for your time.
>
> The result of the vote if we should move to git:
>
> Binding:
> Jacques -0.9
> Nicolas -0.9
> Jacopo -1
> Adam +0
> Scott +0
> Nicolas +0
>
> Non Binding:
> Adrian +0
> Taher Alkhateeb: +1
> Christian Carlow +1
> Pierre +0
> michael.brohl +0
> Christian +0
> Gil portenseigne +0
> Nicolas +0.9
>
> On 05/05/15 10:01, Hans Bakker wrote:
>> As the discussions seem to end, can i propose a vote?
>>
>> The question : should we convert the master SVN repository of Apache
>> OFBIz to a GIT version?
>> The possible answers are according the apache voting guidelines at:
>> https://www.apache.org/foundation/voting.html
>>
>> *
>>
>> +1: 'Yes lets do it'
>>
>> * +0: 'I don't feel strongly about it, but I'm okay with this.'
>> *
>>
>> -0.5: 'I don't like this idea, but I can't find any rational
>> justification for my feelings.'
>>
>> *
>>
>> ++1: 'Wow! I like this! Let's /do/ it!'
>>
>> *
>>
>> -0.9: 'I /really/ don't like this, but I'm not going to stand in the
>> way if everyone else wants to go ahead with it.'
>>
>> *
>>
>> +0.9: 'This is a cool idea and i like it, but I don't have time/the
>> skills necessary to help out.'
>>
>> * -1 'I do not want this.'
>>
>>
>> Votes will be possible for one week from today.
>>
>> Regards,
>> Hans
>>
>> On 20/04/15 11:38, Hans Bakker wrote:
>>> As discussed at apachecon in Austin, i propose to switch from svn to
>>> git for the ofbiz repository. The main reason being that all major
>>> contributors are using git and contributions are cumbersome,
>>> further, git allows for better branching and merging.
>>>
>>> Regards,
>>> Hans
>>
Re: Result: Vote: move to git.
Posted by Christian Carlow <ch...@gmail.com>.
Are git patches acceptable or should they be provided as svn instead?
Command line supports git to svn formatting but I haven't found a way to
do so in eclipse yet. If git isn't an acceptable format I'll make an
effort to convert all the patches I've provided for the past couple of
weeks.
On Tue, 2015-05-12 at 08:19 +0700, Hans Bakker wrote:
> Thank you for the interst and 126 messages on this subject.
>
> Looks like we do not want to go with the technological developments yet.
>
> Thank you all for your time.
>
> The result of the vote if we should move to git:
>
> Binding:
> Jacques -0.9
> Nicolas -0.9
> Jacopo -1
> Adam +0
> Scott +0
> Nicolas +0
>
> Non Binding:
> Adrian +0
> Taher Alkhateeb: +1
> Christian Carlow +1
> Pierre +0
> michael.brohl +0
> Christian +0
> Gil portenseigne +0
> Nicolas +0.9
>
> On 05/05/15 10:01, Hans Bakker wrote:
> > As the discussions seem to end, can i propose a vote?
> >
> > The question : should we convert the master SVN repository of Apache
> > OFBIz to a GIT version?
> > The possible answers are according the apache voting guidelines at:
> > https://www.apache.org/foundation/voting.html
> >
> > *
> >
> > +1: 'Yes lets do it'
> >
> > * +0: 'I don't feel strongly about it, but I'm okay with this.'
> > *
> >
> > -0.5: 'I don't like this idea, but I can't find any rational
> > justification for my feelings.'
> >
> > *
> >
> > ++1: 'Wow! I like this! Let's /do/ it!'
> >
> > *
> >
> > -0.9: 'I /really/ don't like this, but I'm not going to stand in the
> > way if everyone else wants to go ahead with it.'
> >
> > *
> >
> > +0.9: 'This is a cool idea and i like it, but I don't have time/the
> > skills necessary to help out.'
> >
> > * -1 'I do not want this.'
> >
> >
> > Votes will be possible for one week from today.
> >
> > Regards,
> > Hans
> >
> > On 20/04/15 11:38, Hans Bakker wrote:
> >> As discussed at apachecon in Austin, i propose to switch from svn to
> >> git for the ofbiz repository. The main reason being that all major
> >> contributors are using git and contributions are cumbersome, further,
> >> git allows for better branching and merging.
> >>
> >> Regards,
> >> Hans
> >
Result: Vote: move to git.
Posted by Hans Bakker <h....@antwebsystems.com>.
Thank you for the interst and 126 messages on this subject.
Looks like we do not want to go with the technological developments yet.
Thank you all for your time.
The result of the vote if we should move to git:
Binding:
Jacques -0.9
Nicolas -0.9
Jacopo -1
Adam +0
Scott +0
Nicolas +0
Non Binding:
Adrian +0
Taher Alkhateeb: +1
Christian Carlow +1
Pierre +0
michael.brohl +0
Christian +0
Gil portenseigne +0
Nicolas +0.9
On 05/05/15 10:01, Hans Bakker wrote:
> As the discussions seem to end, can i propose a vote?
>
> The question : should we convert the master SVN repository of Apache
> OFBIz to a GIT version?
> The possible answers are according the apache voting guidelines at:
> https://www.apache.org/foundation/voting.html
>
> *
>
> +1: 'Yes lets do it'
>
> * +0: 'I don't feel strongly about it, but I'm okay with this.'
> *
>
> -0.5: 'I don't like this idea, but I can't find any rational
> justification for my feelings.'
>
> *
>
> ++1: 'Wow! I like this! Let's /do/ it!'
>
> *
>
> -0.9: 'I /really/ don't like this, but I'm not going to stand in the
> way if everyone else wants to go ahead with it.'
>
> *
>
> +0.9: 'This is a cool idea and i like it, but I don't have time/the
> skills necessary to help out.'
>
> * -1 'I do not want this.'
>
>
> Votes will be possible for one week from today.
>
> Regards,
> Hans
>
> On 20/04/15 11:38, Hans Bakker wrote:
>> As discussed at apachecon in Austin, i propose to switch from svn to
>> git for the ofbiz repository. The main reason being that all major
>> contributors are using git and contributions are cumbersome, further,
>> git allows for better branching and merging.
>>
>> Regards,
>> Hans
>
Re: Vote: move to git.
Posted by Adam Heath <do...@brainfood.com>.
That's my point as well. These most recent votes have not had concrete
actions attached to them. Without a concrete plan, any kind of +# vote
is not definitive; a +1 could mean anything in these cases.
I chose +0 instead of -0 or -1, as I do believe git is the right
approach, but we need more time to figure out what will change.
* How does the submit-as-patch workflow change with Jira(still allow for
patch, but also allow for fork(clone)/push/merge-request)?
* How to deal with empty directories(svn allows them, git does not)?
* Do we try to support signed commits?
* Should Acked-By, Signed-off-By, etc be adopted as pseudo tags(see the
linux-kernel's use of git)?
* Use pseudo tags for Jira issues?
* What about CLA for all those fork/clone above?
* Who are the Lieutenants, and who is the Dictator(the linux kernel way,
not a suggestion for us)?
* What about line-ending changes? Git has a feature(.gitattributes,
.git/info/attributes) that allow for many different flags to be set;
what would those values be?
These are just off the top of my head.
On 05/05/2015 08:06 AM, Jacopo Cappellato wrote:
> -1
>
> not because I don't like Git or because I don't think it wouldn't be a good fit for OFBiz; the reason for my negative vote is that in the vote there is no mention to the workflow the project will adopt; at the ASF there are some limitations due to Infrastructure and/or license/legal reasons and not all the way Git could be used are allowed (for example I don't think we will be allowed to accept Pull Requests from GitHub).
>
> There are several ASF projects that have switched to Git (https://git-wip-us.apache.org/repos/asf ) but the workflows they have adopted are different from the ones implied by some of the comments in this mailing list; see for example:
> http://karaf.apache.org/index/community/contributing.html (this is very similar to our current svn-based workflow)
> http://wiki.apache.org/hadoop/GitAndHadoop (patch based contributions)
>
> I have mentioned a few times that until someone will take time to review what others do and what can be done @ASF with Git and come up with a proposal for OFBiz, my vote will be negative because it doesn't make any sense to vote for a tool or the other.
>
> Jacopo
>
> On May 5, 2015, at 5:01 AM, Hans Bakker <h....@antwebsystems.com> wrote:
>
>> As the discussions seem to end, can i propose a vote?
>>
>> The question : should we convert the master SVN repository of Apache OFBIz to a GIT version?
>> The possible answers are according the apache voting guidelines at: https://www.apache.org/foundation/voting.html
>>
>> *
>>
>> +1: 'Yes lets do it'
>>
>> * +0: 'I don't feel strongly about it, but I'm okay with this.'
>> *
>>
>> -0.5: 'I don't like this idea, but I can't find any rational
>> justification for my feelings.'
>>
>> *
>>
>> ++1: 'Wow! I like this! Let's /do/ it!'
>>
>> *
>>
>> -0.9: 'I /really/ don't like this, but I'm not going to stand in the
>> way if everyone else wants to go ahead with it.'
>>
>> *
>>
>> +0.9: 'This is a cool idea and i like it, but I don't have time/the
>> skills necessary to help out.'
>>
>> * -1 'I do not want this.'
>>
>>
>> Votes will be possible for one week from today.
>>
>> Regards,
>> Hans
>>
>> On 20/04/15 11:38, Hans Bakker wrote:
>>> As discussed at apachecon in Austin, i propose to switch from svn to git for the ofbiz repository. The main reason being that all major contributors are using git and contributions are cumbersome, further, git allows for better branching and merging.
>>>
>>> Regards,
>>> Hans
Re: Vote: move to git.
Posted by Pierre Smits <pi...@gmail.com>.
Consensus is always needed.
Best regards,
Pierre
Op woensdag 6 mei 2015 heeft Hans Bakker <ma...@antwebsystems.com>
het volgende geschreven:
> Ok let first wait for the vote result seeing your comment at the -1 .
>
> However then still we need a vote again after the proposal... if you make
> it a -0.9 then when the proposal is agreed, no need for a vote.
>
> for people who would like to help, there are plenty of GIT workflow
> proposals in other Apache projects.
>
> Regards,
> Hans
>
> On 06/05/15 14:05, Jacopo Cappellato wrote:
>
>> On May 6, 2015, at 8:56 AM, Hans Bakker <ma...@antwebsystems.com>
>> wrote:
>>
>> When attached to a jira issue, then after approval (or no objection)
>>> merging the patch into the master branch by a committer so difficult?
>>>
>> Did you read the document that you are asking us to refer to as your
>> proposal for the firs Git MVP? The document describes a different workflow
>> because it uses a read only Git repo: no merging on master branch will be
>> possible.
>>
>> Jacopo
>>
>> I am sorry, i do not see a problem here....
>>>
>>> Regards,
>>> Hans
>>>
>>>
>>> On 06/05/15 13:53, Jacopo Cappellato wrote:
>>>
>>>> On May 6, 2015, at 8:46 AM, Hans Bakker <ma...@antwebsystems.com>
>>>> wrote:
>>>>
>>>> the workflow can be simple as is described in:
>>>>> http://www.apache.org/dev/git.html
>>>>>
>>>>> we could use this as the MVP (minimum viable product) so mimic
>>>>> basically how people use SVN and then slowly take advantage of the
>>>>> possibilities of GIT.
>>>>>
>>>>> Regards,
>>>>> Hans
>>>>>
>>>> Hans,
>>>>
>>>> I think you didn't spend enough time studying this material.
>>>> The document you are referencing is what we already have: the workflow
>>>> and infrastructure described are already in place:
>>>> 1) a writable svn repo
>>>> 2) a read only mirror in git: git://git.apache.org/ofbiz.git
>>>> 3) Jira to submit patches
>>>>
>>>> Jacopo
>>>>
>>>> On 06/05/15 13:35, Jacopo Cappellato wrote:
>>>>>
>>>>>> My vote is clearly stated: propose a Git workflow that is inline with
>>>>>> the ASF policies and that is good for the OFBiz project and I will vote
>>>>>> positively.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> On May 6, 2015, at 8:29 AM, Hans Bakker <
>>>>>> mailinglist@antwebsystems.com> wrote:
>>>>>>
>>>>>> Then you better change your vote? At it is now, we cannot even
>>>>>>> create an implementation proposal.
>>>>>>> Hans
>>>>>>>
>>>>>>> On 06/05/15 13:22, Jacopo Cappellato wrote:
>>>>>>>
>>>>>>>> On May 6, 2015, at 3:34 AM, Hans Bakker <h....@antwebsystems.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> It is no use, setting up an implementation plan when there is
>>>>>>>>> still a possibility people will reject it.
>>>>>>>>>
>>>>>>>> Ok, if this was your goal then it seems you got your answer: most
>>>>>>>> people are inclined to Git (or will not object to it) but don't feel like
>>>>>>>> it is actionable enough for a vote now: defining an implementation plan, so
>>>>>>>> that people can understand how the actual every day work of the OFBiz
>>>>>>>> community (committers, contributors and users) with Git will be, would
>>>>>>>> definitely help.
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>
>
--
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
Re: Vote: move to git.
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
On May 6, 2015, at 9:54 AM, Hans Bakker <ma...@antwebsystems.com> wrote:
> After creating a proper plan sure, now formally you have blocked progress with your veto.
The veto is only on commit changes, this vote is not for a commit change so my -1 doesn't count as a veto.
Jacopo
Re: Vote: move to git.
Posted by Christian Geisert <ch...@isu-gmbh.de>.
C'mon Hans
The vote was about "should we convert the master SVN repository of
Apache OFBIz to a GIT version?"
Nobody stops you from creating a proper plan.
Christian
Am 06.05.2015 09:54, schrieb Hans Bakker:
> After creating a proper plan sure, now formally you have blocked
> progress with your veto.
>
> Hans
>
> On 06/05/15 14:16, Jacopo Cappellato wrote:
>> On May 6, 2015, at 9:10 AM, Hans Bakker
>> <ma...@antwebsystems.com> wrote:
>>
>>> However then still we need a vote again after the proposal... if you
>>> make it a -0.9 then when the proposal is agreed, no need for a vote.
>> are you really considering the idea of doing such an important change
>> for the community without a clear and strong indication from it (at
>> least a few +1 votes from his committers)?
>>
>> Jacopo
>
>
Re: Vote: move to git.
Posted by Hans Bakker <ma...@antwebsystems.com>.
After creating a proper plan sure, now formally you have blocked
progress with your veto.
Hans
On 06/05/15 14:16, Jacopo Cappellato wrote:
> On May 6, 2015, at 9:10 AM, Hans Bakker <ma...@antwebsystems.com> wrote:
>
>> However then still we need a vote again after the proposal... if you make it a -0.9 then when the proposal is agreed, no need for a vote.
> are you really considering the idea of doing such an important change for the community without a clear and strong indication from it (at least a few +1 votes from his committers)?
>
> Jacopo
Re: Vote: move to git.
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
On May 6, 2015, at 9:10 AM, Hans Bakker <ma...@antwebsystems.com> wrote:
> However then still we need a vote again after the proposal... if you make it a -0.9 then when the proposal is agreed, no need for a vote.
are you really considering the idea of doing such an important change for the community without a clear and strong indication from it (at least a few +1 votes from his committers)?
Jacopo
Re: Vote: move to git.
Posted by Hans Bakker <ma...@antwebsystems.com>.
Ok let first wait for the vote result seeing your comment at the -1 .
However then still we need a vote again after the proposal... if you
make it a -0.9 then when the proposal is agreed, no need for a vote.
for people who would like to help, there are plenty of GIT workflow
proposals in other Apache projects.
Regards,
Hans
On 06/05/15 14:05, Jacopo Cappellato wrote:
> On May 6, 2015, at 8:56 AM, Hans Bakker <ma...@antwebsystems.com> wrote:
>
>> When attached to a jira issue, then after approval (or no objection) merging the patch into the master branch by a committer so difficult?
> Did you read the document that you are asking us to refer to as your proposal for the firs Git MVP? The document describes a different workflow because it uses a read only Git repo: no merging on master branch will be possible.
>
> Jacopo
>
>> I am sorry, i do not see a problem here....
>>
>> Regards,
>> Hans
>>
>>
>> On 06/05/15 13:53, Jacopo Cappellato wrote:
>>> On May 6, 2015, at 8:46 AM, Hans Bakker <ma...@antwebsystems.com> wrote:
>>>
>>>> the workflow can be simple as is described in:
>>>> http://www.apache.org/dev/git.html
>>>>
>>>> we could use this as the MVP (minimum viable product) so mimic basically how people use SVN and then slowly take advantage of the possibilities of GIT.
>>>>
>>>> Regards,
>>>> Hans
>>> Hans,
>>>
>>> I think you didn't spend enough time studying this material.
>>> The document you are referencing is what we already have: the workflow and infrastructure described are already in place:
>>> 1) a writable svn repo
>>> 2) a read only mirror in git: git://git.apache.org/ofbiz.git
>>> 3) Jira to submit patches
>>>
>>> Jacopo
>>>
>>>> On 06/05/15 13:35, Jacopo Cappellato wrote:
>>>>> My vote is clearly stated: propose a Git workflow that is inline with the ASF policies and that is good for the OFBiz project and I will vote positively.
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On May 6, 2015, at 8:29 AM, Hans Bakker <ma...@antwebsystems.com> wrote:
>>>>>
>>>>>> Then you better change your vote? At it is now, we cannot even create an implementation proposal.
>>>>>> Hans
>>>>>>
>>>>>> On 06/05/15 13:22, Jacopo Cappellato wrote:
>>>>>>> On May 6, 2015, at 3:34 AM, Hans Bakker <h....@antwebsystems.com> wrote:
>>>>>>>
>>>>>>>> It is no use, setting up an implementation plan when there is still a possibility people will reject it.
>>>>>>> Ok, if this was your goal then it seems you got your answer: most people are inclined to Git (or will not object to it) but don't feel like it is actionable enough for a vote now: defining an implementation plan, so that people can understand how the actual every day work of the OFBiz community (committers, contributors and users) with Git will be, would definitely help.
>>>>>>>
>>>>>>> Jacopo
Re: Vote: move to git.
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
On May 6, 2015, at 8:56 AM, Hans Bakker <ma...@antwebsystems.com> wrote:
> When attached to a jira issue, then after approval (or no objection) merging the patch into the master branch by a committer so difficult?
Did you read the document that you are asking us to refer to as your proposal for the firs Git MVP? The document describes a different workflow because it uses a read only Git repo: no merging on master branch will be possible.
Jacopo
>
> I am sorry, i do not see a problem here....
>
> Regards,
> Hans
>
>
> On 06/05/15 13:53, Jacopo Cappellato wrote:
>> On May 6, 2015, at 8:46 AM, Hans Bakker <ma...@antwebsystems.com> wrote:
>>
>>> the workflow can be simple as is described in:
>>> http://www.apache.org/dev/git.html
>>>
>>> we could use this as the MVP (minimum viable product) so mimic basically how people use SVN and then slowly take advantage of the possibilities of GIT.
>>>
>>> Regards,
>>> Hans
>> Hans,
>>
>> I think you didn't spend enough time studying this material.
>> The document you are referencing is what we already have: the workflow and infrastructure described are already in place:
>> 1) a writable svn repo
>> 2) a read only mirror in git: git://git.apache.org/ofbiz.git
>> 3) Jira to submit patches
>>
>> Jacopo
>>
>>> On 06/05/15 13:35, Jacopo Cappellato wrote:
>>>> My vote is clearly stated: propose a Git workflow that is inline with the ASF policies and that is good for the OFBiz project and I will vote positively.
>>>>
>>>> Jacopo
>>>>
>>>> On May 6, 2015, at 8:29 AM, Hans Bakker <ma...@antwebsystems.com> wrote:
>>>>
>>>>> Then you better change your vote? At it is now, we cannot even create an implementation proposal.
>>>>> Hans
>>>>>
>>>>> On 06/05/15 13:22, Jacopo Cappellato wrote:
>>>>>> On May 6, 2015, at 3:34 AM, Hans Bakker <h....@antwebsystems.com> wrote:
>>>>>>
>>>>>>> It is no use, setting up an implementation plan when there is still a possibility people will reject it.
>>>>>> Ok, if this was your goal then it seems you got your answer: most people are inclined to Git (or will not object to it) but don't feel like it is actionable enough for a vote now: defining an implementation plan, so that people can understand how the actual every day work of the OFBiz community (committers, contributors and users) with Git will be, would definitely help.
>>>>>>
>>>>>> Jacopo
>
Re: Vote: move to git.
Posted by Hans Bakker <ma...@antwebsystems.com>.
When attached to a jira issue, then after approval (or no objection)
merging the patch into the master branch by a committer so difficult?
I am sorry, i do not see a problem here....
Regards,
Hans
On 06/05/15 13:53, Jacopo Cappellato wrote:
> On May 6, 2015, at 8:46 AM, Hans Bakker <ma...@antwebsystems.com> wrote:
>
>> the workflow can be simple as is described in:
>> http://www.apache.org/dev/git.html
>>
>> we could use this as the MVP (minimum viable product) so mimic basically how people use SVN and then slowly take advantage of the possibilities of GIT.
>>
>> Regards,
>> Hans
> Hans,
>
> I think you didn't spend enough time studying this material.
> The document you are referencing is what we already have: the workflow and infrastructure described are already in place:
> 1) a writable svn repo
> 2) a read only mirror in git: git://git.apache.org/ofbiz.git
> 3) Jira to submit patches
>
> Jacopo
>
>> On 06/05/15 13:35, Jacopo Cappellato wrote:
>>> My vote is clearly stated: propose a Git workflow that is inline with the ASF policies and that is good for the OFBiz project and I will vote positively.
>>>
>>> Jacopo
>>>
>>> On May 6, 2015, at 8:29 AM, Hans Bakker <ma...@antwebsystems.com> wrote:
>>>
>>>> Then you better change your vote? At it is now, we cannot even create an implementation proposal.
>>>> Hans
>>>>
>>>> On 06/05/15 13:22, Jacopo Cappellato wrote:
>>>>> On May 6, 2015, at 3:34 AM, Hans Bakker <h....@antwebsystems.com> wrote:
>>>>>
>>>>>> It is no use, setting up an implementation plan when there is still a possibility people will reject it.
>>>>> Ok, if this was your goal then it seems you got your answer: most people are inclined to Git (or will not object to it) but don't feel like it is actionable enough for a vote now: defining an implementation plan, so that people can understand how the actual every day work of the OFBiz community (committers, contributors and users) with Git will be, would definitely help.
>>>>>
>>>>> Jacopo
Re: Vote: move to git.
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
On May 6, 2015, at 8:46 AM, Hans Bakker <ma...@antwebsystems.com> wrote:
> the workflow can be simple as is described in:
> http://www.apache.org/dev/git.html
>
> we could use this as the MVP (minimum viable product) so mimic basically how people use SVN and then slowly take advantage of the possibilities of GIT.
>
> Regards,
> Hans
Hans,
I think you didn't spend enough time studying this material.
The document you are referencing is what we already have: the workflow and infrastructure described are already in place:
1) a writable svn repo
2) a read only mirror in git: git://git.apache.org/ofbiz.git
3) Jira to submit patches
Jacopo
>
> On 06/05/15 13:35, Jacopo Cappellato wrote:
>> My vote is clearly stated: propose a Git workflow that is inline with the ASF policies and that is good for the OFBiz project and I will vote positively.
>>
>> Jacopo
>>
>> On May 6, 2015, at 8:29 AM, Hans Bakker <ma...@antwebsystems.com> wrote:
>>
>>> Then you better change your vote? At it is now, we cannot even create an implementation proposal.
>>> Hans
>>>
>>> On 06/05/15 13:22, Jacopo Cappellato wrote:
>>>> On May 6, 2015, at 3:34 AM, Hans Bakker <h....@antwebsystems.com> wrote:
>>>>
>>>>> It is no use, setting up an implementation plan when there is still a possibility people will reject it.
>>>> Ok, if this was your goal then it seems you got your answer: most people are inclined to Git (or will not object to it) but don't feel like it is actionable enough for a vote now: defining an implementation plan, so that people can understand how the actual every day work of the OFBiz community (committers, contributors and users) with Git will be, would definitely help.
>>>>
>>>> Jacopo
>
Re: Vote: move to git.
Posted by Hans Bakker <ma...@antwebsystems.com>.
the workflow can be simple as is described in:
http://www.apache.org/dev/git.html
we could use this as the MVP (minimum viable product) so mimic basically
how people use SVN and then slowly take advantage of the possibilities
of GIT.
Regards,
Hans
On 06/05/15 13:35, Jacopo Cappellato wrote:
> My vote is clearly stated: propose a Git workflow that is inline with the ASF policies and that is good for the OFBiz project and I will vote positively.
>
> Jacopo
>
> On May 6, 2015, at 8:29 AM, Hans Bakker <ma...@antwebsystems.com> wrote:
>
>> Then you better change your vote? At it is now, we cannot even create an implementation proposal.
>> Hans
>>
>> On 06/05/15 13:22, Jacopo Cappellato wrote:
>>> On May 6, 2015, at 3:34 AM, Hans Bakker <h....@antwebsystems.com> wrote:
>>>
>>>> It is no use, setting up an implementation plan when there is still a possibility people will reject it.
>>> Ok, if this was your goal then it seems you got your answer: most people are inclined to Git (or will not object to it) but don't feel like it is actionable enough for a vote now: defining an implementation plan, so that people can understand how the actual every day work of the OFBiz community (committers, contributors and users) with Git will be, would definitely help.
>>>
>>> Jacopo
Re: Vote: move to git.
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
On May 6, 2015, at 8:43 AM, Taher Alkhateeb <sl...@gmail.com> wrote:
> Hi Jacopo,
>
> I am a bit of a noob on ASF policies. Is it possible to guide us on
> resources to read to be able to draft any kind of proposal?
Hi Taher,
please read my previous messages on this subject because they contain some of the information you are looking for.
A good document to start with could be this:
http://www.apache.org/dev/writable-git
and also the documents referred to it.
Then also a review of the workflow adopted by other ASF project that switched to git may help to get some good ideas for OFBiz; the projects are the following:
https://git-wip-us.apache.org/repos/asf
By visiting their websites/wikis/mail archives we could gather useful information about their experience and lessons learned; what the ASF allows and what not.
> Can you also
> define what is an implementation plan? Is it like a document, a migration
> process, a commit workflow, infrastructure or what exactly?
I wouldn't use the term "implementation plan" that was introduced by Hans: what I am asking for is essentially a description of the commit workflow proposed for OFBiz. Then we could compare it to what we have now and discuss its pros and cons.
Jacopo
>
> Taher Alkhateeb
>
> On Wed, May 6, 2015 at 9:35 AM, Jacopo Cappellato <
> jacopo.cappellato@hotwaxsystems.com> wrote:
>
>> My vote is clearly stated: propose a Git workflow that is inline with the
>> ASF policies and that is good for the OFBiz project and I will vote
>> positively.
>>
>> Jacopo
>>
>> On May 6, 2015, at 8:29 AM, Hans Bakker <ma...@antwebsystems.com>
>> wrote:
>>
>>> Then you better change your vote? At it is now, we cannot even create an
>> implementation proposal.
>>> Hans
>>>
>>> On 06/05/15 13:22, Jacopo Cappellato wrote:
>>>> On May 6, 2015, at 3:34 AM, Hans Bakker <h....@antwebsystems.com>
>> wrote:
>>>>
>>>>> It is no use, setting up an implementation plan when there is still a
>> possibility people will reject it.
>>>> Ok, if this was your goal then it seems you got your answer: most
>> people are inclined to Git (or will not object to it) but don't feel like
>> it is actionable enough for a vote now: defining an implementation plan, so
>> that people can understand how the actual every day work of the OFBiz
>> community (committers, contributors and users) with Git will be, would
>> definitely help.
>>>>
>>>> Jacopo
>>>
>>
>>
Re: Vote: move to git.
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Jacopo,
I am a bit of a noob on ASF policies. Is it possible to guide us on
resources to read to be able to draft any kind of proposal? Can you also
define what is an implementation plan? Is it like a document, a migration
process, a commit workflow, infrastructure or what exactly?
Taher Alkhateeb
On Wed, May 6, 2015 at 9:35 AM, Jacopo Cappellato <
jacopo.cappellato@hotwaxsystems.com> wrote:
> My vote is clearly stated: propose a Git workflow that is inline with the
> ASF policies and that is good for the OFBiz project and I will vote
> positively.
>
> Jacopo
>
> On May 6, 2015, at 8:29 AM, Hans Bakker <ma...@antwebsystems.com>
> wrote:
>
> > Then you better change your vote? At it is now, we cannot even create an
> implementation proposal.
> > Hans
> >
> > On 06/05/15 13:22, Jacopo Cappellato wrote:
> >> On May 6, 2015, at 3:34 AM, Hans Bakker <h....@antwebsystems.com>
> wrote:
> >>
> >>> It is no use, setting up an implementation plan when there is still a
> possibility people will reject it.
> >> Ok, if this was your goal then it seems you got your answer: most
> people are inclined to Git (or will not object to it) but don't feel like
> it is actionable enough for a vote now: defining an implementation plan, so
> that people can understand how the actual every day work of the OFBiz
> community (committers, contributors and users) with Git will be, would
> definitely help.
> >>
> >> Jacopo
> >
>
>
Re: Vote: move to git.
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
My vote is clearly stated: propose a Git workflow that is inline with the ASF policies and that is good for the OFBiz project and I will vote positively.
Jacopo
On May 6, 2015, at 8:29 AM, Hans Bakker <ma...@antwebsystems.com> wrote:
> Then you better change your vote? At it is now, we cannot even create an implementation proposal.
> Hans
>
> On 06/05/15 13:22, Jacopo Cappellato wrote:
>> On May 6, 2015, at 3:34 AM, Hans Bakker <h....@antwebsystems.com> wrote:
>>
>>> It is no use, setting up an implementation plan when there is still a possibility people will reject it.
>> Ok, if this was your goal then it seems you got your answer: most people are inclined to Git (or will not object to it) but don't feel like it is actionable enough for a vote now: defining an implementation plan, so that people can understand how the actual every day work of the OFBiz community (committers, contributors and users) with Git will be, would definitely help.
>>
>> Jacopo
>
Re: Vote: move to git.
Posted by Hans Bakker <ma...@antwebsystems.com>.
Then you better change your vote? At it is now, we cannot even create an
implementation proposal.
Hans
On 06/05/15 13:22, Jacopo Cappellato wrote:
> On May 6, 2015, at 3:34 AM, Hans Bakker <h....@antwebsystems.com> wrote:
>
>> It is no use, setting up an implementation plan when there is still a possibility people will reject it.
> Ok, if this was your goal then it seems you got your answer: most people are inclined to Git (or will not object to it) but don't feel like it is actionable enough for a vote now: defining an implementation plan, so that people can understand how the actual every day work of the OFBiz community (committers, contributors and users) with Git will be, would definitely help.
>
> Jacopo
Re: Vote: move to git.
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
On May 6, 2015, at 3:34 AM, Hans Bakker <h....@antwebsystems.com> wrote:
> It is no use, setting up an implementation plan when there is still a possibility people will reject it.
Ok, if this was your goal then it seems you got your answer: most people are inclined to Git (or will not object to it) but don't feel like it is actionable enough for a vote now: defining an implementation plan, so that people can understand how the actual every day work of the OFBiz community (committers, contributors and users) with Git will be, would definitely help.
Jacopo
Re: Vote: move to git.
Posted by Hans Bakker <h....@antwebsystems.com>.
Jacopo,
This vote was about IF we choose to go to Git, if the answer is yes,
sure then we need an implementation plan.
It is no use, setting up an implementation plan when there is still a
possibility people will reject it.
Regards,
Hans
PS. We really have to change the way we work here, I admire Adam,
spending so much time on maven when people can still reject it.
On 05/05/15 20:06, Jacopo Cappellato wrote:
> -1
>
> not because I don't like Git or because I don't think it wouldn't be a good fit for OFBiz; the reason for my negative vote is that in the vote there is no mention to the workflow the project will adopt; at the ASF there are some limitations due to Infrastructure and/or license/legal reasons and not all the way Git could be used are allowed (for example I don't think we will be allowed to accept Pull Requests from GitHub).
>
> There are several ASF projects that have switched to Git (https://git-wip-us.apache.org/repos/asf ) but the workflows they have adopted are different from the ones implied by some of the comments in this mailing list; see for example:
> http://karaf.apache.org/index/community/contributing.html (this is very similar to our current svn-based workflow)
> http://wiki.apache.org/hadoop/GitAndHadoop (patch based contributions)
>
> I have mentioned a few times that until someone will take time to review what others do and what can be done @ASF with Git and come up with a proposal for OFBiz, my vote will be negative because it doesn't make any sense to vote for a tool or the other.
>
> Jacopo
>
> On May 5, 2015, at 5:01 AM, Hans Bakker <h....@antwebsystems.com> wrote:
>
>> As the discussions seem to end, can i propose a vote?
>>
>> The question : should we convert the master SVN repository of Apache OFBIz to a GIT version?
>> The possible answers are according the apache voting guidelines at: https://www.apache.org/foundation/voting.html
>>
>> *
>>
>> +1: 'Yes lets do it'
>>
>> * +0: 'I don't feel strongly about it, but I'm okay with this.'
>> *
>>
>> -0.5: 'I don't like this idea, but I can't find any rational
>> justification for my feelings.'
>>
>> *
>>
>> ++1: 'Wow! I like this! Let's /do/ it!'
>>
>> *
>>
>> -0.9: 'I /really/ don't like this, but I'm not going to stand in the
>> way if everyone else wants to go ahead with it.'
>>
>> *
>>
>> +0.9: 'This is a cool idea and i like it, but I don't have time/the
>> skills necessary to help out.'
>>
>> * -1 'I do not want this.'
>>
>>
>> Votes will be possible for one week from today.
>>
>> Regards,
>> Hans
>>
>> On 20/04/15 11:38, Hans Bakker wrote:
>>> As discussed at apachecon in Austin, i propose to switch from svn to git for the ofbiz repository. The main reason being that all major contributors are using git and contributions are cumbersome, further, git allows for better branching and merging.
>>>
>>> Regards,
>>> Hans
Re: Vote: move to git.
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
-1
not because I don't like Git or because I don't think it wouldn't be a good fit for OFBiz; the reason for my negative vote is that in the vote there is no mention to the workflow the project will adopt; at the ASF there are some limitations due to Infrastructure and/or license/legal reasons and not all the way Git could be used are allowed (for example I don't think we will be allowed to accept Pull Requests from GitHub).
There are several ASF projects that have switched to Git (https://git-wip-us.apache.org/repos/asf ) but the workflows they have adopted are different from the ones implied by some of the comments in this mailing list; see for example:
http://karaf.apache.org/index/community/contributing.html (this is very similar to our current svn-based workflow)
http://wiki.apache.org/hadoop/GitAndHadoop (patch based contributions)
I have mentioned a few times that until someone will take time to review what others do and what can be done @ASF with Git and come up with a proposal for OFBiz, my vote will be negative because it doesn't make any sense to vote for a tool or the other.
Jacopo
On May 5, 2015, at 5:01 AM, Hans Bakker <h....@antwebsystems.com> wrote:
> As the discussions seem to end, can i propose a vote?
>
> The question : should we convert the master SVN repository of Apache OFBIz to a GIT version?
> The possible answers are according the apache voting guidelines at: https://www.apache.org/foundation/voting.html
>
> *
>
> +1: 'Yes lets do it'
>
> * +0: 'I don't feel strongly about it, but I'm okay with this.'
> *
>
> -0.5: 'I don't like this idea, but I can't find any rational
> justification for my feelings.'
>
> *
>
> ++1: 'Wow! I like this! Let's /do/ it!'
>
> *
>
> -0.9: 'I /really/ don't like this, but I'm not going to stand in the
> way if everyone else wants to go ahead with it.'
>
> *
>
> +0.9: 'This is a cool idea and i like it, but I don't have time/the
> skills necessary to help out.'
>
> * -1 'I do not want this.'
>
>
> Votes will be possible for one week from today.
>
> Regards,
> Hans
>
> On 20/04/15 11:38, Hans Bakker wrote:
>> As discussed at apachecon in Austin, i propose to switch from svn to git for the ofbiz repository. The main reason being that all major contributors are using git and contributions are cumbersome, further, git allows for better branching and merging.
>>
>> Regards,
>> Hans
>
Re: Vote: move to git.
Posted by Michael Brohl <mi...@ecomify.de>.
+0
Git is a great tool once you understand the mechanisms and get used to it.
But I also think that it might be too early to make it the main source
control for the project. It takes extra effort for some and the
committers have to handle pull requests and such.
With the other bigger sub projects in mind (Maven, Moqui etc.) I think
we should not force it right now. The benefits are not that strong.
Regards,
Michael Brohl
ecomify GmbH
www.ecomify.de
Am 05.05.15 um 05:01 schrieb Hans Bakker:
> As the discussions seem to end, can i propose a vote?
>
> The question : should we convert the master SVN repository of Apache
> OFBIz to a GIT version?
> The possible answers are according the apache voting guidelines at:
> https://www.apache.org/foundation/voting.html
>
> *
>
> +1: 'Yes lets do it'
>
> * +0: 'I don't feel strongly about it, but I'm okay with this.'
> *
>
> -0.5: 'I don't like this idea, but I can't find any rational
> justification for my feelings.'
>
> *
>
> ++1: 'Wow! I like this! Let's /do/ it!'
>
> *
>
> -0.9: 'I /really/ don't like this, but I'm not going to stand in the
> way if everyone else wants to go ahead with it.'
>
> *
>
> +0.9: 'This is a cool idea and i like it, but I don't have time/the
> skills necessary to help out.'
>
> * -1 'I do not want this.'
>
>
> Votes will be possible for one week from today.
>
> Regards,
> Hans
>
> On 20/04/15 11:38, Hans Bakker wrote:
>> As discussed at apachecon in Austin, i propose to switch from svn to
>> git for the ofbiz repository. The main reason being that all major
>> contributors are using git and contributions are cumbersome, further,
>> git allows for better branching and merging.
>>
>> Regards,
>> Hans
>
Re: Vote: move to git.
Posted by Adrian Crum <ad...@sandglass-software.com>.
+0
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 5/4/2015 8:01 PM, Hans Bakker wrote:
> As the discussions seem to end, can i propose a vote?
>
> The question : should we convert the master SVN repository of Apache
> OFBIz to a GIT version?
> The possible answers are according the apache voting guidelines at:
> https://www.apache.org/foundation/voting.html
>
> *
>
> +1: 'Yes lets do it'
>
> * +0: 'I don't feel strongly about it, but I'm okay with this.'
> *
>
> -0.5: 'I don't like this idea, but I can't find any rational
> justification for my feelings.'
>
> *
>
> ++1: 'Wow! I like this! Let's /do/ it!'
>
> *
>
> -0.9: 'I /really/ don't like this, but I'm not going to stand in the
> way if everyone else wants to go ahead with it.'
>
> *
>
> +0.9: 'This is a cool idea and i like it, but I don't have time/the
> skills necessary to help out.'
>
> * -1 'I do not want this.'
>
>
> Votes will be possible for one week from today.
>
> Regards,
> Hans
>
> On 20/04/15 11:38, Hans Bakker wrote:
>> As discussed at apachecon in Austin, i propose to switch from svn to
>> git for the ofbiz repository. The main reason being that all major
>> contributors are using git and contributions are cumbersome, further,
>> git allows for better branching and merging.
>>
>> Regards,
>> Hans
>
Re: Vote: move to git.
Posted by Gil portenseigne <gi...@nereide.fr>.
+0
On 05/05/2015 05:01, Hans Bakker wrote:
> As the discussions seem to end, can i propose a vote?
>
> The question : should we convert the master SVN repository of Apache
> OFBIz to a GIT version?
> The possible answers are according the apache voting guidelines at:
> https://www.apache.org/foundation/voting.html
>
> *
>
> +1: 'Yes lets do it'
>
> * +0: 'I don't feel strongly about it, but I'm okay with this.'
> *
>
> -0.5: 'I don't like this idea, but I can't find any rational
> justification for my feelings.'
>
> *
>
> ++1: 'Wow! I like this! Let's /do/ it!'
>
> *
>
> -0.9: 'I /really/ don't like this, but I'm not going to stand in the
> way if everyone else wants to go ahead with it.'
>
> *
>
> +0.9: 'This is a cool idea and i like it, but I don't have time/the
> skills necessary to help out.'
>
> * -1 'I do not want this.'
>
>
> Votes will be possible for one week from today.
>
> Regards,
> Hans
>
> On 20/04/15 11:38, Hans Bakker wrote:
>> As discussed at apachecon in Austin, i propose to switch from svn to
>> git for the ofbiz repository. The main reason being that all major
>> contributors are using git and contributions are cumbersome, further,
>> git allows for better branching and merging.
>>
>> Regards,
>> Hans
>
Re: Vote: move to git.
Posted by Scott Gray <sc...@hotwaxsystems.com>.
+0
I like git and use it primarily but I'm not sure that adoption of git at
the ASF has reached the point where I'm prepared to force it onto the
unwilling.
On 5 May 2015 15:01, "Hans Bakker" <h....@antwebsystems.com> wrote:
> As the discussions seem to end, can i propose a vote?
>
> The question : should we convert the master SVN repository of Apache OFBIz
> to a GIT version?
> The possible answers are according the apache voting guidelines at:
> https://www.apache.org/foundation/voting.html
>
> *
>
> +1: 'Yes lets do it'
>
> * +0: 'I don't feel strongly about it, but I'm okay with this.'
> *
>
> -0.5: 'I don't like this idea, but I can't find any rational
> justification for my feelings.'
>
> *
>
> ++1: 'Wow! I like this! Let's /do/ it!'
>
> *
>
> -0.9: 'I /really/ don't like this, but I'm not going to stand in the
> way if everyone else wants to go ahead with it.'
>
> *
>
> +0.9: 'This is a cool idea and i like it, but I don't have time/the
> skills necessary to help out.'
>
> * -1 'I do not want this.'
>
>
> Votes will be possible for one week from today.
>
> Regards,
> Hans
>
> On 20/04/15 11:38, Hans Bakker wrote:
>
>> As discussed at apachecon in Austin, i propose to switch from svn to git
>> for the ofbiz repository. The main reason being that all major contributors
>> are using git and contributions are cumbersome, further, git allows for
>> better branching and merging.
>>
>> Regards,
>> Hans
>>
>
>
Vote: move to git.
Posted by Hans Bakker <h....@antwebsystems.com>.
As the discussions seem to end, can i propose a vote?
The question : should we convert the master SVN repository of Apache
OFBIz to a GIT version?
The possible answers are according the apache voting guidelines at:
https://www.apache.org/foundation/voting.html
*
+1: 'Yes lets do it'
* +0: 'I don't feel strongly about it, but I'm okay with this.'
*
-0.5: 'I don't like this idea, but I can't find any rational
justification for my feelings.'
*
++1: 'Wow! I like this! Let's /do/ it!'
*
-0.9: 'I /really/ don't like this, but I'm not going to stand in the
way if everyone else wants to go ahead with it.'
*
+0.9: 'This is a cool idea and i like it, but I don't have time/the
skills necessary to help out.'
* -1 'I do not want this.'
Votes will be possible for one week from today.
Regards,
Hans
On 20/04/15 11:38, Hans Bakker wrote:
> As discussed at apachecon in Austin, i propose to switch from svn to
> git for the ofbiz repository. The main reason being that all major
> contributors are using git and contributions are cumbersome, further,
> git allows for better branching and merging.
>
> Regards,
> Hans
Re: move to git.
Posted by Nicolas Malin <ni...@nereide.fr>.
Le 20/04/2015 09:53, Adrian Crum a écrit :
> I find Git to be an overly complicated solution to a simple problem.
I have the same feeling
Nicolas
Re: move to git.
Posted by Adrian Crum <ad...@sandglass-software.com>.
That wasn't what happened to me. Here are the steps I took and the outcome:
1. Git pull to update my local copy.
2. Make changes to 4 files.
3. Stash push.
4. Pull to get latest repo changes.
5. Stash pop.
6. Commit - 4 files changed.
7. Push - dozens of files changed.
!!!???
8. Check commit log - 4 files changed.
Why did my push change dozens of files I didn't touch? Basically,
several days of other people's work were reverted by my push.
My local copy says I changed only 4 files, but a diff of the repo before
and after my push shows that many more files were changed. Even the Git
gurus couldn't figure that out. Meanwhile, the unintended changes had to
be fixed by hand.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 4/21/2015 1:12 AM, Adam Heath wrote:
> I used to be in the same boat; in the early days, I would blame git for
> losing my work. "Damn you frigging piece of software!"
>
> However, I also realized that the linux-kernel was using it to do much
> more complex things than I was, so I toiled on. It took me a long time,
> but I was finally able to figure out how to make use of git's features.
>
> The main thing that keeps you from losing work, is to commit
> *everything* to git. If you leave *anything* in your $working_tree, not
> committed, then yes, sometimes things get confused. But once you have
> everything committed to git, there are certain things that git helps you
> with, with regard to keeping copies of stuff around.
>
> ==
> # git config --global rerere.enabled true
> # (echo adfadsfasdf; date) > new-file
> # git branch before-new-file
> # git add new-file
> # git commit -m "This is my cool new file, yipee!"
> # git log
> # git checkout before-new-file
> # git branch -f master before-new-file
> # git checkout master
> # ls new-file # hmm, where did it go?
> # git reflog # hmm, seems to show the commit from above
> # git log trunk # commit is gone
> # git log trunk@{1} # this shows the commit, and the file
> ==
>
> This is just one of the powerful features that git has. I have rerere
> enabled locally, but don't use it often. I enabled it long ago, because
> I saw that it keeps copies of all my rebasing and branching, so that I
> can feel safer about having this safety net.
>
> Also, I when back in time, and found an older copy of the previous ofbiz
> svn tree, and "underlayed" it into the current git-svn checkout, so I
> have git history going all the way back to 2003.
>
> On 04/20/2015 02:53 AM, Adrian Crum wrote:
>> I don't agree that "all major contributors are using git."
>>
>> Personally, I find Git to be an overly complicated solution to a
>> simple problem. It frequently does bizarre things that no one
>> understands, and you are left with things being mysteriously reverted
>> for unknown reasons.
>>
>> This isn't a -1 vote though. I'm just making it clear that I will be
>> dragged kicking and screaming into using it.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 4/20/2015 5:38 AM, Hans Bakker wrote:
>>> As discussed at apachecon in Austin, i propose to switch from svn to git
>>> for the ofbiz repository. The main reason being that all major
>>> contributors are using git and contributions are cumbersome, further,
>>> git allows for better branching and merging.
>>>
>>> Regards,
>>> Hans
>
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 21/04/2015 02:14, Adam Heath a écrit :
>
> On 04/20/2015 07:12 PM, Adam Heath wrote:
>> I used to be in the same boat; in the early days, I would blame git for losing my work. "Damn you frigging piece of software!"
>>
>> However, I also realized that the linux-kernel was using it to do much more complex things than I was, so I toiled on. It took me a long time, but
>> I was finally able to figure out how to make use of git's features.
Dare I point the linux-kernel and OFBiz are somehow different? We have 18 active committers, I guess linux-kernel has (much?) more...
I read it's even organised in a hierarchy http://stackoverflow.com/questions/4166530/how-to-manage-a-hierarchy-of-committers-like-linux-kernel-dev
I believe Git was created because Linus needed to delegate but still have the control... Why do we need to switch form Svn to Git is my question?
I prefer to focus on other fields in OFBiz like
"OFBiz : open or in progress" https://issues.apache.org/jira/issues/?filter=12311912#
"Patch Available in OFBiz" https://issues.apache.org/jira/issues/?filter=12314132
>>
>> The main thing that keeps you from losing work, is to commit *everything* to git. If you leave *anything* in your $working_tree, not committed,
>> then yes, sometimes things get confused. But once you have everything committed to git, there are certain things that git helps you with, with
>> regard to keeping copies of stuff around.
>>
>> ==
>> # git config --global rerere.enabled true
>> # (echo adfadsfasdf; date) > new-file
>> # git branch before-new-file
>> # git add new-file
>> # git commit -m "This is my cool new file, yipee!"
>> # git log
>> # git checkout before-new-file
>> # git branch -f master before-new-file
>> # git checkout master
>> # ls new-file # hmm, where did it go?
>> # git reflog # hmm, seems to show the commit from above
>> # git log trunk # commit is gone
>> # git log trunk@{1} # this shows the commit, and the file
>> ==
>>
>
> Gah, too many git features. git rerere is a feature to cache rebase resolutions; the feature being discussed here is not the same thing.
>
Well, so I need to dive deep in Git, but what for? Do I really miss that as an OFBiz committer? I hope you see my preferences...
Jacques
>> This is just one of the powerful features that git has. I have rerere enabled locally, but don't use it often. I enabled it long ago, because I
>> saw that it keeps copies of all my rebasing and branching, so that I can feel safer about having this safety net.
>>
>> Also, I when back in time, and found an older copy of the previous ofbiz svn tree, and "underlayed" it into the current git-svn checkout, so I have
>> git history going all the way back to 2003.
>>
>> On 04/20/2015 02:53 AM, Adrian Crum wrote:
>>> I don't agree that "all major contributors are using git."
>>>
>>> Personally, I find Git to be an overly complicated solution to a simple problem. It frequently does bizarre things that no one understands, and
>>> you are left with things being mysteriously reverted for unknown reasons.
>>>
>>> This isn't a -1 vote though. I'm just making it clear that I will be dragged kicking and screaming into using it.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>> On 4/20/2015 5:38 AM, Hans Bakker wrote:
>>>> As discussed at apachecon in Austin, i propose to switch from svn to git
>>>> for the ofbiz repository. The main reason being that all major
>>>> contributors are using git and contributions are cumbersome, further,
>>>> git allows for better branching and merging.
>>>>
>>>> Regards,
>>>> Hans
>>
>
>
Re: move to git.
Posted by Adam Heath <do...@brainfood.com>.
On 04/20/2015 07:12 PM, Adam Heath wrote:
> I used to be in the same boat; in the early days, I would blame git
> for losing my work. "Damn you frigging piece of software!"
>
> However, I also realized that the linux-kernel was using it to do much
> more complex things than I was, so I toiled on. It took me a long
> time, but I was finally able to figure out how to make use of git's
> features.
>
> The main thing that keeps you from losing work, is to commit
> *everything* to git. If you leave *anything* in your $working_tree,
> not committed, then yes, sometimes things get confused. But once you
> have everything committed to git, there are certain things that git
> helps you with, with regard to keeping copies of stuff around.
>
> ==
> # git config --global rerere.enabled true
> # (echo adfadsfasdf; date) > new-file
> # git branch before-new-file
> # git add new-file
> # git commit -m "This is my cool new file, yipee!"
> # git log
> # git checkout before-new-file
> # git branch -f master before-new-file
> # git checkout master
> # ls new-file # hmm, where did it go?
> # git reflog # hmm, seems to show the commit from above
> # git log trunk # commit is gone
> # git log trunk@{1} # this shows the commit, and the file
> ==
>
Gah, too many git features. git rerere is a feature to cache rebase
resolutions; the feature being discussed here is not the same thing.
> This is just one of the powerful features that git has. I have rerere
> enabled locally, but don't use it often. I enabled it long ago,
> because I saw that it keeps copies of all my rebasing and branching,
> so that I can feel safer about having this safety net.
>
> Also, I when back in time, and found an older copy of the previous
> ofbiz svn tree, and "underlayed" it into the current git-svn checkout,
> so I have git history going all the way back to 2003.
>
> On 04/20/2015 02:53 AM, Adrian Crum wrote:
>> I don't agree that "all major contributors are using git."
>>
>> Personally, I find Git to be an overly complicated solution to a
>> simple problem. It frequently does bizarre things that no one
>> understands, and you are left with things being mysteriously reverted
>> for unknown reasons.
>>
>> This isn't a -1 vote though. I'm just making it clear that I will be
>> dragged kicking and screaming into using it.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 4/20/2015 5:38 AM, Hans Bakker wrote:
>>> As discussed at apachecon in Austin, i propose to switch from svn to
>>> git
>>> for the ofbiz repository. The main reason being that all major
>>> contributors are using git and contributions are cumbersome, further,
>>> git allows for better branching and merging.
>>>
>>> Regards,
>>> Hans
>
Re: move to git.
Posted by Adam Heath <do...@brainfood.com>.
I used to be in the same boat; in the early days, I would blame git for
losing my work. "Damn you frigging piece of software!"
However, I also realized that the linux-kernel was using it to do much
more complex things than I was, so I toiled on. It took me a long time,
but I was finally able to figure out how to make use of git's features.
The main thing that keeps you from losing work, is to commit
*everything* to git. If you leave *anything* in your $working_tree, not
committed, then yes, sometimes things get confused. But once you have
everything committed to git, there are certain things that git helps you
with, with regard to keeping copies of stuff around.
==
# git config --global rerere.enabled true
# (echo adfadsfasdf; date) > new-file
# git branch before-new-file
# git add new-file
# git commit -m "This is my cool new file, yipee!"
# git log
# git checkout before-new-file
# git branch -f master before-new-file
# git checkout master
# ls new-file # hmm, where did it go?
# git reflog # hmm, seems to show the commit from above
# git log trunk # commit is gone
# git log trunk@{1} # this shows the commit, and the file
==
This is just one of the powerful features that git has. I have rerere
enabled locally, but don't use it often. I enabled it long ago, because
I saw that it keeps copies of all my rebasing and branching, so that I
can feel safer about having this safety net.
Also, I when back in time, and found an older copy of the previous ofbiz
svn tree, and "underlayed" it into the current git-svn checkout, so I
have git history going all the way back to 2003.
On 04/20/2015 02:53 AM, Adrian Crum wrote:
> I don't agree that "all major contributors are using git."
>
> Personally, I find Git to be an overly complicated solution to a
> simple problem. It frequently does bizarre things that no one
> understands, and you are left with things being mysteriously reverted
> for unknown reasons.
>
> This isn't a -1 vote though. I'm just making it clear that I will be
> dragged kicking and screaming into using it.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 4/20/2015 5:38 AM, Hans Bakker wrote:
>> As discussed at apachecon in Austin, i propose to switch from svn to git
>> for the ofbiz repository. The main reason being that all major
>> contributors are using git and contributions are cumbersome, further,
>> git allows for better branching and merging.
>>
>> Regards,
>> Hans
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 23/04/2015 17:50, Adam Heath a écrit :
> Ok, everything passes, git svn dcommit $HASH, flood the mailing list.
"flood the mailing list", you said it :p
Jacques
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Since Svn 1.7 (or 1.6?) the .svn files are no longer scattered all over but in a .svn folder at root of the WC
Jacques
Le 23/04/2015 17:50, Adam Heath a écrit :
> Let's not forgot that the complete project history is available offline, that the .svn files are not scattered all over
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 23/04/2015 17:50, Adam Heath a écrit :
> As for that last item I mentioned, if we do switch, I would *love* to include such ancient history.
That would be a plus indeed...
Jacques
Re: move to git.
Posted by Adam Heath <do...@brainfood.com>.
On 04/23/2015 03:28 AM, Scott Gray wrote:
> "I am thoroughly familiar with Git."
> "Git always screws things up."
If git always screwed things up, then those other 3 projects wouldn't be
using it.
ps: I realize this was a quote from Adrian, and not Scott.
> These two statements are complete contradictions. Outcomes in git only
> appear strange while you're still unfamiliar with it.
>
> I've been using the git-svn bridge to commit to OFBiz for about 4 years and
> using a git repo on my current project for the last 18 months or so.
> Strange occurrences stopped happening for me after a couple of months and
> generally stopped once all developers either stopped using git client UIs
> that used settings they didn't understand or they started using the command
> line (which is exceedingly simple for basic workflows).
I also had strangeness happen earlier on, when I first started. What I
can surmise happened, after all these years, is that I used git in the
wrong way, and git did exactly what I told it to do. But then, since I
was a noob, I didn't know what I had done was wrong, only that what I
was seeing was not what I expected.
It's the same kind of thing when you go "rm -rf $HOME". Of course all
your files are now gone, but that's not the fault of rm.
> The value of feature branches and pull requests over patches cannot be
> overstated IMO. The ability to easily multi-task on features, review pull
> requests, keep a real commit history for contributed features, to
> collaborate outside of the main repo puts git miles ahead of svn for
> collaborative incremental software development.
Let's not forgot that the complete project history is available offline,
that the .svn files are not scattered all over(which makes grepping for
stuff difficult, as you have to exclude those files from results), that
you can include ancient history from previous project lifespans(I have
added svn.ofbiz.org history in one of my git-svn ofbiz clones, so I can
see history going back to 2003, well before the switch to apache, and
even when Andrew created a new repo with the mostly current component
structure).
As for that last item I mentioned, if we do switch, I would *love* to
include such ancient history.
Then, how do you(not you Scott) thing I can commit 15 changes all at
once? I do all that work in a single commit. Then I save it. Then, I
use git rebase, and split the commit into smaller chunks. Woops, that's
a new feature, let's change the order of the commits, moving that one
first. Oh, my bad, I have a typo in a commit message, let's change
that. Ok, I'm happy now, time to run all tests against every single
commit(while I switch jobs and work on something else). Ok, everything
passes, git svn dcommit $HASH, flood the mailing list.
In the svn workflow, only a single patch can be committed at a time, and
you have to manually save local work, to build up the patch history.
Git actually allows me to produce more stable code, when I am splitting
up single-large-commits.
> Regards
> Scott
>
>
> On 20 April 2015 at 22:19, Adrian Crum <ad...@sandglass-software.com>
> wrote:
>
>> I am thoroughly familiar with Git. I've used it on on three projects, and
>> that is why I don't like it.
>>
>> I have a far easier time merging branches with Subversion. Git always
>> screws things up.
>>
>> I don't need to be convinced of anything. I have my experience and my
>> opinion. But still, I'm not opposed to switching to Git.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 4/20/2015 11:08 AM, Taher Alkhateeb wrote:
>>
>>> One of the most difficult and challenging issue with branches is _merging_
>>> them. Git is a tool that is far more advanced in its feature set in that
>>> area.
>>>
>>> It seems some of the opinions expressed against git are due to
>>> unfamiliarity. The only way to be convinced is to try it on an advanced
>>> level as i don't think an email thread would be enough for convincing
>>> anyone of the merits.
>>>
>>> My 2 cents
>>>
>>> Taher Alkhateeb
>>> On Apr 20, 2015 12:54 PM, "Pierre Smits" <pi...@gmail.com> wrote:
>>>
>>> If we only want GIT for multiple local development branches, then we are
>>>> doing for the wrong reasons. SVN doesn't hinder you in doing that today.
>>>>
>>>> Best regards,
>>>>
>>>> Pierre Smits
>>>>
>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>> Services & Solutions for Cloud-
>>>> Based Manufacturing, Professional
>>>> Services and Retail & Trade
>>>> http://www.orrtiz.com
>>>>
>>>> On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux <
>>>> jacques.le.roux@les7arts.com> wrote:
>>>>
>>>> Like Adrian and mostly for the same reasons, I don't believe we need
>>>>> Git.
>>>>>
>>>>> But there is one other major reason which has already been discussed in
>>>>> the other common ASF MLs. As Taher exulted, it's possible to create
>>>>>
>>>> local
>>>>
>>>>> branches. So people are able to do a lot of work alone without
>>>>> exchanging
>>>>> before committing or submitting. It will certainly not help to have this
>>>>> possibility. Remember our recent discussion on the lack or core commits
>>>>> reviews. With Git you end with commits bursts or big patches and it's
>>>>>
>>>> then
>>>>
>>>>> hard to review and too late to share ideas.
>>>>>
>>>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>>>>>
>>>> use
>>>>
>>>>> a -1 if necessary!
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 20/04/2015 09:53, Adrian Crum a écrit :
>>>>>
>>>>> I don't agree that "all major contributors are using git."
>>>>>> Personally, I find Git to be an overly complicated solution to a simple
>>>>>> problem. It frequently does bizarre things that no one understands, and
>>>>>>
>>>>> you
>>>>> are left with things being mysteriously reverted for unknown reasons.
>>>>>> This isn't a -1 vote though. I'm just making it clear that I will be
>>>>>> dragged kicking and screaming into using it.
>>>>>>
>>>>>> Adrian Crum
>>>>>> Sandglass Software
>>>>>> www.sandglass-software.com
>>>>>>
>>>>>> On 4/20/2015 5:38 AM, Hans Bakker wrote:
>>>>>>
>>>>>> As discussed at apachecon in Austin, i propose to switch from svn to
>>>>>> git
>>>>> for the ofbiz repository. The main reason being that all major
>>>>>>> contributors are using git and contributions are cumbersome, further,
>>>>>>> git allows for better branching and merging.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Hans
>>>>>>>
>>>>>>>
>>>>>>
Re: move to git.
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
On Apr 23, 2015, at 11:42 AM, Martin Becker <ma...@ecomify.de> wrote:
> Maybe it’s necessary to think about which processes and workflows maybe the ones that are expected by the current and especially future audience/clients/contributors from a state of the art, living and ongoing open source project.
Exactly. I think that we are having a thorough discussion on the pros and cons of git vs svn, which is good, but we are not focusing enough, in my opinion, on the existing workflows and if/how they should change with the adoption of a new tool.
For example, I guess that some of us are implying that with the new tool (git) will also come a new workflow and specifically the "Fork workflow" that is the one made easy by GitHub and similar: there is one official repo, developer fork it and then submit pull request that the committers of the official (upstream) repo can merge.
However this is not the only one and it is important that we clarify this aspect: do all proponent of git also agree on one workflow?
Another important aspect of the story is that, for policy/license reasons, while it is completely fine for an ASF project to use git as the primary SCM, there are things that they still cannot do (e.g. I think that merging code from pull requests is not allowed); the current git workflow that is recommended at the ASF is the following:
non committers: https://git-wip-us.apache.org/docs/workflow.html
committers: https://git-wip-us.apache.org/docs/committer-practices.html
Jacopo
Re: move to git.
Posted by Martin Becker <ma...@ecomify.de>.
> Strange occurrences stopped happening for me after a couple of months and
> generally stopped once all developers either stopped using git client UIs
> that used settings they didn't understand or they started using the command
> line…
That’s my experience, too, and therefore one of my reasons to not love git so far. I’m a command line guy, but for daily „commit" work i miss the overview an the usability of a UI that I can rely on. But this is a mainly „layer 8“ problem…
In my opinion, the main aspect is the decision for a different workflow for contributing and managing this project with its opportunities and drawbacks, as stated widely in this thread. Maybe it’s necessary to think about which processes and workflows maybe the ones that are expected by the current and especially future audience/clients/contributors from a state of the art, living and ongoing open source project.
Martin Becker
ecomify GmbH
> Am 23.04.2015 um 10:28 schrieb Scott Gray <sc...@hotwaxsystems.com>:
>
> "I am thoroughly familiar with Git."
> "Git always screws things up."
>
> These two statements are complete contradictions. Outcomes in git only
> appear strange while you're still unfamiliar with it.
>
> I've been using the git-svn bridge to commit to OFBiz for about 4 years and
> using a git repo on my current project for the last 18 months or so.
> Strange occurrences stopped happening for me after a couple of months and
> generally stopped once all developers either stopped using git client UIs
> that used settings they didn't understand or they started using the command
> line (which is exceedingly simple for basic workflows).
>
> The value of feature branches and pull requests over patches cannot be
> overstated IMO. The ability to easily multi-task on features, review pull
> requests, keep a real commit history for contributed features, to
> collaborate outside of the main repo puts git miles ahead of svn for
> collaborative incremental software development.
>
> Regards
> Scott
>
>
> On 20 April 2015 at 22:19, Adrian Crum <ad...@sandglass-software.com>
> wrote:
>
>> I am thoroughly familiar with Git. I've used it on on three projects, and
>> that is why I don't like it.
>>
>> I have a far easier time merging branches with Subversion. Git always
>> screws things up.
>>
>> I don't need to be convinced of anything. I have my experience and my
>> opinion. But still, I'm not opposed to switching to Git.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 4/20/2015 11:08 AM, Taher Alkhateeb wrote:
>>
>>> One of the most difficult and challenging issue with branches is _merging_
>>> them. Git is a tool that is far more advanced in its feature set in that
>>> area.
>>>
>>> It seems some of the opinions expressed against git are due to
>>> unfamiliarity. The only way to be convinced is to try it on an advanced
>>> level as i don't think an email thread would be enough for convincing
>>> anyone of the merits.
>>>
>>> My 2 cents
>>>
>>> Taher Alkhateeb
>>> On Apr 20, 2015 12:54 PM, "Pierre Smits" <pi...@gmail.com> wrote:
>>>
>>> If we only want GIT for multiple local development branches, then we are
>>>> doing for the wrong reasons. SVN doesn't hinder you in doing that today.
>>>>
>>>> Best regards,
>>>>
>>>> Pierre Smits
>>>>
>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>> Services & Solutions for Cloud-
>>>> Based Manufacturing, Professional
>>>> Services and Retail & Trade
>>>> http://www.orrtiz.com
>>>>
>>>> On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux <
>>>> jacques.le.roux@les7arts.com> wrote:
>>>>
>>>> Like Adrian and mostly for the same reasons, I don't believe we need
>>>>> Git.
>>>>>
>>>>> But there is one other major reason which has already been discussed in
>>>>> the other common ASF MLs. As Taher exulted, it's possible to create
>>>>>
>>>> local
>>>>
>>>>> branches. So people are able to do a lot of work alone without
>>>>> exchanging
>>>>> before committing or submitting. It will certainly not help to have this
>>>>> possibility. Remember our recent discussion on the lack or core commits
>>>>> reviews. With Git you end with commits bursts or big patches and it's
>>>>>
>>>> then
>>>>
>>>>> hard to review and too late to share ideas.
>>>>>
>>>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>>>>>
>>>> use
>>>>
>>>>> a -1 if necessary!
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 20/04/2015 09:53, Adrian Crum a écrit :
>>>>>
>>>>> I don't agree that "all major contributors are using git."
>>>>>>
>>>>>> Personally, I find Git to be an overly complicated solution to a simple
>>>>>> problem. It frequently does bizarre things that no one understands, and
>>>>>>
>>>>> you
>>>>
>>>>> are left with things being mysteriously reverted for unknown reasons.
>>>>>>
>>>>>> This isn't a -1 vote though. I'm just making it clear that I will be
>>>>>> dragged kicking and screaming into using it.
>>>>>>
>>>>>> Adrian Crum
>>>>>> Sandglass Software
>>>>>> www.sandglass-software.com
>>>>>>
>>>>>> On 4/20/2015 5:38 AM, Hans Bakker wrote:
>>>>>>
>>>>>> As discussed at apachecon in Austin, i propose to switch from svn to
>>>>>>>
>>>>>> git
>>>>
>>>>> for the ofbiz repository. The main reason being that all major
>>>>>>> contributors are using git and contributions are cumbersome, further,
>>>>>>> git allows for better branching and merging.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Hans
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
Re: move to git.
Posted by Adrian Crum <ad...@sandglass-software.com>.
> I can imagine
> the mess someone might make trying to rewrite history on the remote repo.
That is what I am imagining also.
When/if the vote occurs to make the change, I will vote +0 - because I
don't like using Git, but I don't want to stand in the way of others
using it.
I'm looking forward to the benefits of the switch, but at the same time
I will most likely be the one who makes a mess of things in the main repo.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 4/23/2015 10:22 AM, Scott Gray wrote:
> I'm just saying my current project has been using it for 18 months and it's
> been a long time now since we've "lost" any changes. This is 15-30 devs
> that were all new to git.
>
> In my experience most issues come from:
> - Reverting merge commits and picking the wrong mainline
> - Pushing to the wrong remote branch
> - Incorrectly handling conflicts
> - Trying to force pushes
>
> The most important thing is to stop when you mess something up and seek
> help. Trying to fix things on the remote repo without understanding what
> has gone wrong can make a bigger mess.
>
> On second thought I'm almost hesitant to say git would be a good idea for
> OFBiz because we have so many committers that would have access to the
> master branch without an adequate level of git experience. I can imagine
> the mess someone might make trying to rewrite history on the remote repo.
>
> Regardless, I highly recommend git-svn for basic local development
> or forking the git mirror if you want to go deeper.
>
> Regards
> Scott
>
> On 23 April 2015 at 20:59, Adrian Crum <ad...@sandglass-software.com>
> wrote:
>
>> They are contradictions because they have been taken out of context.
>>
>> I was responding to the suggestion that I don't like Git because I have
>> never used it. I have used it on three projects, and there have been
>> problems - even when "Git experts" use it. So, my dislike is based on my
>> experiences with Git, not on my lack of experience with it.
>>
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 4/23/2015 9:28 AM, Scott Gray wrote:
>>
>>> "I am thoroughly familiar with Git."
>>> "Git always screws things up."
>>>
>>> These two statements are complete contradictions. Outcomes in git only
>>> appear strange while you're still unfamiliar with it.
>>>
>>> I've been using the git-svn bridge to commit to OFBiz for about 4 years
>>> and
>>> using a git repo on my current project for the last 18 months or so.
>>> Strange occurrences stopped happening for me after a couple of months and
>>> generally stopped once all developers either stopped using git client UIs
>>> that used settings they didn't understand or they started using the
>>> command
>>> line (which is exceedingly simple for basic workflows).
>>>
>>> The value of feature branches and pull requests over patches cannot be
>>> overstated IMO. The ability to easily multi-task on features, review pull
>>> requests, keep a real commit history for contributed features, to
>>> collaborate outside of the main repo puts git miles ahead of svn for
>>> collaborative incremental software development.
>>>
>>> Regards
>>> Scott
>>>
>>>
>>> On 20 April 2015 at 22:19, Adrian Crum <
>>> adrian.crum@sandglass-software.com>
>>> wrote:
>>>
>>> I am thoroughly familiar with Git. I've used it on on three projects, and
>>>> that is why I don't like it.
>>>>
>>>> I have a far easier time merging branches with Subversion. Git always
>>>> screws things up.
>>>>
>>>> I don't need to be convinced of anything. I have my experience and my
>>>> opinion. But still, I'm not opposed to switching to Git.
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 4/20/2015 11:08 AM, Taher Alkhateeb wrote:
>>>>
>>>> One of the most difficult and challenging issue with branches is
>>>>> _merging_
>>>>> them. Git is a tool that is far more advanced in its feature set in that
>>>>> area.
>>>>>
>>>>> It seems some of the opinions expressed against git are due to
>>>>> unfamiliarity. The only way to be convinced is to try it on an advanced
>>>>> level as i don't think an email thread would be enough for convincing
>>>>> anyone of the merits.
>>>>>
>>>>> My 2 cents
>>>>>
>>>>> Taher Alkhateeb
>>>>> On Apr 20, 2015 12:54 PM, "Pierre Smits" <pi...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> If we only want GIT for multiple local development branches, then we
>>>>> are
>>>>>
>>>>>> doing for the wrong reasons. SVN doesn't hinder you in doing that
>>>>>> today.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Pierre Smits
>>>>>>
>>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>>> Services & Solutions for Cloud-
>>>>>> Based Manufacturing, Professional
>>>>>> Services and Retail & Trade
>>>>>> http://www.orrtiz.com
>>>>>>
>>>>>> On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux <
>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>
>>>>>> Like Adrian and mostly for the same reasons, I don't believe we need
>>>>>>
>>>>>>> Git.
>>>>>>>
>>>>>>> But there is one other major reason which has already been discussed
>>>>>>> in
>>>>>>> the other common ASF MLs. As Taher exulted, it's possible to create
>>>>>>>
>>>>>>> local
>>>>>>
>>>>>> branches. So people are able to do a lot of work alone without
>>>>>>> exchanging
>>>>>>> before committing or submitting. It will certainly not help to have
>>>>>>> this
>>>>>>> possibility. Remember our recent discussion on the lack or core
>>>>>>> commits
>>>>>>> reviews. With Git you end with commits bursts or big patches and it's
>>>>>>>
>>>>>>> then
>>>>>>
>>>>>> hard to review and too late to share ideas.
>>>>>>>
>>>>>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>>>>>>>
>>>>>>> use
>>>>>>
>>>>>> a -1 if necessary!
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>> Le 20/04/2015 09:53, Adrian Crum a écrit :
>>>>>>>
>>>>>>> I don't agree that "all major contributors are using git."
>>>>>>>
>>>>>>>>
>>>>>>>> Personally, I find Git to be an overly complicated solution to a
>>>>>>>> simple
>>>>>>>> problem. It frequently does bizarre things that no one understands,
>>>>>>>> and
>>>>>>>>
>>>>>>>> you
>>>>>>>
>>>>>>
>>>>>> are left with things being mysteriously reverted for unknown reasons.
>>>>>>>
>>>>>>>>
>>>>>>>> This isn't a -1 vote though. I'm just making it clear that I will be
>>>>>>>> dragged kicking and screaming into using it.
>>>>>>>>
>>>>>>>> Adrian Crum
>>>>>>>> Sandglass Software
>>>>>>>> www.sandglass-software.com
>>>>>>>>
>>>>>>>> On 4/20/2015 5:38 AM, Hans Bakker wrote:
>>>>>>>>
>>>>>>>> As discussed at apachecon in Austin, i propose to switch from svn
>>>>>>>> to
>>>>>>>>
>>>>>>>>>
>>>>>>>>> git
>>>>>>>>
>>>>>>>
>>>>>> for the ofbiz repository. The main reason being that all major
>>>>>>>
>>>>>>>> contributors are using git and contributions are cumbersome, further,
>>>>>>>>> git allows for better branching and merging.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Hans
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>
>
Re: move to git.
Posted by Adam Heath <do...@brainfood.com>.
On 04/23/2015 04:22 AM, Scott Gray wrote:
> I'm just saying my current project has been using it for 18 months and it's
> been a long time now since we've "lost" any changes. This is 15-30 devs
> that were all new to git.
>
> In my experience most issues come from:
> - Reverting merge commits and picking the wrong mainline
Yeah, I've had issues here too. I generally don't do git reset HEAD^
when it's a merge, instead I do "git branch save-current; git checkout
save-current; git branch -F master $HASH; git checkout master". If all
went well, then I can delete that save-current branch, and continue on.
> - Pushing to the wrong remote branch
If caught before anyone else pulls, git push +local-ref:remote-ref can fix.
> - Incorrectly handling conflicts
This single item was a cause for much head-ache, at least for me. Merge
conflicts, and rebase conflicts, are given different markup as well,
which doesn't help the situation.
Conflicts happen with both git and svn based workflows. If you attempt
to commit with svn, and someone else modified the files first, svn says
no. So then you pull in the upstream changes, and attempt to fix
locally. It's still possible to pick the wrong code. The issue now is
that when you commit back to svn, it's not recorded as a merge, there is
no special text saying which files had conflict, so you are left to
assume the developer meant to change the code.
> - Trying to force pushes
Also related, is pushing to a remote repo, that is also checked out(aka,
has a $working_directory), and the remote branch being pushed to is what
is checked out.
> The most important thing is to stop when you mess something up and seek
> help. Trying to fix things on the remote repo without understanding what
> has gone wrong can make a bigger mess.
When I had problems earlier on, I got very frustrated. After a bit, I
realized I could abuse the garbage-collection nature of git, and create
a temporary branch against HEAD, before I changed anything. Git would
ensure that the content referenced by that branch would stay around,
while I made mistakes.
Eventually, I started to make use of reflog directly, and no longer need
that temporary branch.
> On second thought I'm almost hesitant to say git would be a good idea for
> OFBiz because we have so many committers that would have access to the
> master branch without an adequate level of git experience. I can imagine
> the mess someone might make trying to rewrite history on the remote repo.
The linux-kernel does not have all developers world-wide pushing to the
single repo that is responsible for producing the tarballs hosted at
kernel.org. Only one guy does that, Linus Torvalds.
Implicit in a svn->git switch, would be finding someone willing to be
that person. Which, is a whole other thread of discussion.
> Regardless, I highly recommend git-svn for basic local development
> or forking the git mirror if you want to go deeper.
I've been saying that for years.
Re: move to git.
Posted by Scott Gray <sc...@hotwaxsystems.com>.
I'm just saying my current project has been using it for 18 months and it's
been a long time now since we've "lost" any changes. This is 15-30 devs
that were all new to git.
In my experience most issues come from:
- Reverting merge commits and picking the wrong mainline
- Pushing to the wrong remote branch
- Incorrectly handling conflicts
- Trying to force pushes
The most important thing is to stop when you mess something up and seek
help. Trying to fix things on the remote repo without understanding what
has gone wrong can make a bigger mess.
On second thought I'm almost hesitant to say git would be a good idea for
OFBiz because we have so many committers that would have access to the
master branch without an adequate level of git experience. I can imagine
the mess someone might make trying to rewrite history on the remote repo.
Regardless, I highly recommend git-svn for basic local development
or forking the git mirror if you want to go deeper.
Regards
Scott
On 23 April 2015 at 20:59, Adrian Crum <ad...@sandglass-software.com>
wrote:
> They are contradictions because they have been taken out of context.
>
> I was responding to the suggestion that I don't like Git because I have
> never used it. I have used it on three projects, and there have been
> problems - even when "Git experts" use it. So, my dislike is based on my
> experiences with Git, not on my lack of experience with it.
>
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 4/23/2015 9:28 AM, Scott Gray wrote:
>
>> "I am thoroughly familiar with Git."
>> "Git always screws things up."
>>
>> These two statements are complete contradictions. Outcomes in git only
>> appear strange while you're still unfamiliar with it.
>>
>> I've been using the git-svn bridge to commit to OFBiz for about 4 years
>> and
>> using a git repo on my current project for the last 18 months or so.
>> Strange occurrences stopped happening for me after a couple of months and
>> generally stopped once all developers either stopped using git client UIs
>> that used settings they didn't understand or they started using the
>> command
>> line (which is exceedingly simple for basic workflows).
>>
>> The value of feature branches and pull requests over patches cannot be
>> overstated IMO. The ability to easily multi-task on features, review pull
>> requests, keep a real commit history for contributed features, to
>> collaborate outside of the main repo puts git miles ahead of svn for
>> collaborative incremental software development.
>>
>> Regards
>> Scott
>>
>>
>> On 20 April 2015 at 22:19, Adrian Crum <
>> adrian.crum@sandglass-software.com>
>> wrote:
>>
>> I am thoroughly familiar with Git. I've used it on on three projects, and
>>> that is why I don't like it.
>>>
>>> I have a far easier time merging branches with Subversion. Git always
>>> screws things up.
>>>
>>> I don't need to be convinced of anything. I have my experience and my
>>> opinion. But still, I'm not opposed to switching to Git.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>> On 4/20/2015 11:08 AM, Taher Alkhateeb wrote:
>>>
>>> One of the most difficult and challenging issue with branches is
>>>> _merging_
>>>> them. Git is a tool that is far more advanced in its feature set in that
>>>> area.
>>>>
>>>> It seems some of the opinions expressed against git are due to
>>>> unfamiliarity. The only way to be convinced is to try it on an advanced
>>>> level as i don't think an email thread would be enough for convincing
>>>> anyone of the merits.
>>>>
>>>> My 2 cents
>>>>
>>>> Taher Alkhateeb
>>>> On Apr 20, 2015 12:54 PM, "Pierre Smits" <pi...@gmail.com>
>>>> wrote:
>>>>
>>>> If we only want GIT for multiple local development branches, then we
>>>> are
>>>>
>>>>> doing for the wrong reasons. SVN doesn't hinder you in doing that
>>>>> today.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Pierre Smits
>>>>>
>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>> Services & Solutions for Cloud-
>>>>> Based Manufacturing, Professional
>>>>> Services and Retail & Trade
>>>>> http://www.orrtiz.com
>>>>>
>>>>> On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux <
>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>
>>>>> Like Adrian and mostly for the same reasons, I don't believe we need
>>>>>
>>>>>> Git.
>>>>>>
>>>>>> But there is one other major reason which has already been discussed
>>>>>> in
>>>>>> the other common ASF MLs. As Taher exulted, it's possible to create
>>>>>>
>>>>>> local
>>>>>
>>>>> branches. So people are able to do a lot of work alone without
>>>>>> exchanging
>>>>>> before committing or submitting. It will certainly not help to have
>>>>>> this
>>>>>> possibility. Remember our recent discussion on the lack or core
>>>>>> commits
>>>>>> reviews. With Git you end with commits bursts or big patches and it's
>>>>>>
>>>>>> then
>>>>>
>>>>> hard to review and too late to share ideas.
>>>>>>
>>>>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>>>>>>
>>>>>> use
>>>>>
>>>>> a -1 if necessary!
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>> Le 20/04/2015 09:53, Adrian Crum a écrit :
>>>>>>
>>>>>> I don't agree that "all major contributors are using git."
>>>>>>
>>>>>>>
>>>>>>> Personally, I find Git to be an overly complicated solution to a
>>>>>>> simple
>>>>>>> problem. It frequently does bizarre things that no one understands,
>>>>>>> and
>>>>>>>
>>>>>>> you
>>>>>>
>>>>>
>>>>> are left with things being mysteriously reverted for unknown reasons.
>>>>>>
>>>>>>>
>>>>>>> This isn't a -1 vote though. I'm just making it clear that I will be
>>>>>>> dragged kicking and screaming into using it.
>>>>>>>
>>>>>>> Adrian Crum
>>>>>>> Sandglass Software
>>>>>>> www.sandglass-software.com
>>>>>>>
>>>>>>> On 4/20/2015 5:38 AM, Hans Bakker wrote:
>>>>>>>
>>>>>>> As discussed at apachecon in Austin, i propose to switch from svn
>>>>>>> to
>>>>>>>
>>>>>>>>
>>>>>>>> git
>>>>>>>
>>>>>>
>>>>> for the ofbiz repository. The main reason being that all major
>>>>>>
>>>>>>> contributors are using git and contributions are cumbersome, further,
>>>>>>>> git allows for better branching and merging.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Hans
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>
Re: move to git.
Posted by Adrian Crum <ad...@sandglass-software.com>.
They are contradictions because they have been taken out of context.
I was responding to the suggestion that I don't like Git because I have
never used it. I have used it on three projects, and there have been
problems - even when "Git experts" use it. So, my dislike is based on my
experiences with Git, not on my lack of experience with it.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 4/23/2015 9:28 AM, Scott Gray wrote:
> "I am thoroughly familiar with Git."
> "Git always screws things up."
>
> These two statements are complete contradictions. Outcomes in git only
> appear strange while you're still unfamiliar with it.
>
> I've been using the git-svn bridge to commit to OFBiz for about 4 years and
> using a git repo on my current project for the last 18 months or so.
> Strange occurrences stopped happening for me after a couple of months and
> generally stopped once all developers either stopped using git client UIs
> that used settings they didn't understand or they started using the command
> line (which is exceedingly simple for basic workflows).
>
> The value of feature branches and pull requests over patches cannot be
> overstated IMO. The ability to easily multi-task on features, review pull
> requests, keep a real commit history for contributed features, to
> collaborate outside of the main repo puts git miles ahead of svn for
> collaborative incremental software development.
>
> Regards
> Scott
>
>
> On 20 April 2015 at 22:19, Adrian Crum <ad...@sandglass-software.com>
> wrote:
>
>> I am thoroughly familiar with Git. I've used it on on three projects, and
>> that is why I don't like it.
>>
>> I have a far easier time merging branches with Subversion. Git always
>> screws things up.
>>
>> I don't need to be convinced of anything. I have my experience and my
>> opinion. But still, I'm not opposed to switching to Git.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 4/20/2015 11:08 AM, Taher Alkhateeb wrote:
>>
>>> One of the most difficult and challenging issue with branches is _merging_
>>> them. Git is a tool that is far more advanced in its feature set in that
>>> area.
>>>
>>> It seems some of the opinions expressed against git are due to
>>> unfamiliarity. The only way to be convinced is to try it on an advanced
>>> level as i don't think an email thread would be enough for convincing
>>> anyone of the merits.
>>>
>>> My 2 cents
>>>
>>> Taher Alkhateeb
>>> On Apr 20, 2015 12:54 PM, "Pierre Smits" <pi...@gmail.com> wrote:
>>>
>>> If we only want GIT for multiple local development branches, then we are
>>>> doing for the wrong reasons. SVN doesn't hinder you in doing that today.
>>>>
>>>> Best regards,
>>>>
>>>> Pierre Smits
>>>>
>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>> Services & Solutions for Cloud-
>>>> Based Manufacturing, Professional
>>>> Services and Retail & Trade
>>>> http://www.orrtiz.com
>>>>
>>>> On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux <
>>>> jacques.le.roux@les7arts.com> wrote:
>>>>
>>>> Like Adrian and mostly for the same reasons, I don't believe we need
>>>>> Git.
>>>>>
>>>>> But there is one other major reason which has already been discussed in
>>>>> the other common ASF MLs. As Taher exulted, it's possible to create
>>>>>
>>>> local
>>>>
>>>>> branches. So people are able to do a lot of work alone without
>>>>> exchanging
>>>>> before committing or submitting. It will certainly not help to have this
>>>>> possibility. Remember our recent discussion on the lack or core commits
>>>>> reviews. With Git you end with commits bursts or big patches and it's
>>>>>
>>>> then
>>>>
>>>>> hard to review and too late to share ideas.
>>>>>
>>>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>>>>>
>>>> use
>>>>
>>>>> a -1 if necessary!
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 20/04/2015 09:53, Adrian Crum a écrit :
>>>>>
>>>>> I don't agree that "all major contributors are using git."
>>>>>>
>>>>>> Personally, I find Git to be an overly complicated solution to a simple
>>>>>> problem. It frequently does bizarre things that no one understands, and
>>>>>>
>>>>> you
>>>>
>>>>> are left with things being mysteriously reverted for unknown reasons.
>>>>>>
>>>>>> This isn't a -1 vote though. I'm just making it clear that I will be
>>>>>> dragged kicking and screaming into using it.
>>>>>>
>>>>>> Adrian Crum
>>>>>> Sandglass Software
>>>>>> www.sandglass-software.com
>>>>>>
>>>>>> On 4/20/2015 5:38 AM, Hans Bakker wrote:
>>>>>>
>>>>>> As discussed at apachecon in Austin, i propose to switch from svn to
>>>>>>>
>>>>>> git
>>>>
>>>>> for the ofbiz repository. The main reason being that all major
>>>>>>> contributors are using git and contributions are cumbersome, further,
>>>>>>> git allows for better branching and merging.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Hans
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>
Re: move to git.
Posted by Scott Gray <sc...@hotwaxsystems.com>.
"I am thoroughly familiar with Git."
"Git always screws things up."
These two statements are complete contradictions. Outcomes in git only
appear strange while you're still unfamiliar with it.
I've been using the git-svn bridge to commit to OFBiz for about 4 years and
using a git repo on my current project for the last 18 months or so.
Strange occurrences stopped happening for me after a couple of months and
generally stopped once all developers either stopped using git client UIs
that used settings they didn't understand or they started using the command
line (which is exceedingly simple for basic workflows).
The value of feature branches and pull requests over patches cannot be
overstated IMO. The ability to easily multi-task on features, review pull
requests, keep a real commit history for contributed features, to
collaborate outside of the main repo puts git miles ahead of svn for
collaborative incremental software development.
Regards
Scott
On 20 April 2015 at 22:19, Adrian Crum <ad...@sandglass-software.com>
wrote:
> I am thoroughly familiar with Git. I've used it on on three projects, and
> that is why I don't like it.
>
> I have a far easier time merging branches with Subversion. Git always
> screws things up.
>
> I don't need to be convinced of anything. I have my experience and my
> opinion. But still, I'm not opposed to switching to Git.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 4/20/2015 11:08 AM, Taher Alkhateeb wrote:
>
>> One of the most difficult and challenging issue with branches is _merging_
>> them. Git is a tool that is far more advanced in its feature set in that
>> area.
>>
>> It seems some of the opinions expressed against git are due to
>> unfamiliarity. The only way to be convinced is to try it on an advanced
>> level as i don't think an email thread would be enough for convincing
>> anyone of the merits.
>>
>> My 2 cents
>>
>> Taher Alkhateeb
>> On Apr 20, 2015 12:54 PM, "Pierre Smits" <pi...@gmail.com> wrote:
>>
>> If we only want GIT for multiple local development branches, then we are
>>> doing for the wrong reasons. SVN doesn't hinder you in doing that today.
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>> Like Adrian and mostly for the same reasons, I don't believe we need
>>>> Git.
>>>>
>>>> But there is one other major reason which has already been discussed in
>>>> the other common ASF MLs. As Taher exulted, it's possible to create
>>>>
>>> local
>>>
>>>> branches. So people are able to do a lot of work alone without
>>>> exchanging
>>>> before committing or submitting. It will certainly not help to have this
>>>> possibility. Remember our recent discussion on the lack or core commits
>>>> reviews. With Git you end with commits bursts or big patches and it's
>>>>
>>> then
>>>
>>>> hard to review and too late to share ideas.
>>>>
>>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>>>>
>>> use
>>>
>>>> a -1 if necessary!
>>>>
>>>> Jacques
>>>>
>>>>
>>>> Le 20/04/2015 09:53, Adrian Crum a écrit :
>>>>
>>>> I don't agree that "all major contributors are using git."
>>>>>
>>>>> Personally, I find Git to be an overly complicated solution to a simple
>>>>> problem. It frequently does bizarre things that no one understands, and
>>>>>
>>>> you
>>>
>>>> are left with things being mysteriously reverted for unknown reasons.
>>>>>
>>>>> This isn't a -1 vote though. I'm just making it clear that I will be
>>>>> dragged kicking and screaming into using it.
>>>>>
>>>>> Adrian Crum
>>>>> Sandglass Software
>>>>> www.sandglass-software.com
>>>>>
>>>>> On 4/20/2015 5:38 AM, Hans Bakker wrote:
>>>>>
>>>>> As discussed at apachecon in Austin, i propose to switch from svn to
>>>>>>
>>>>> git
>>>
>>>> for the ofbiz repository. The main reason being that all major
>>>>>> contributors are using git and contributions are cumbersome, further,
>>>>>> git allows for better branching and merging.
>>>>>>
>>>>>> Regards,
>>>>>> Hans
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Sorry, I mean I second Adrian's explanation which is obviously not to vote for moving to Git
And If you read the thread you will see I already said: " a -1 if necessary!"
Jacques
Le 20/04/2015 13:05, Pierre Smits a écrit :
> @Jacques: is your +1 to be regarded as a yes vote fore moving to git? I am
> getting confused somehow.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Mon, Apr 20, 2015 at 1:01 PM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> +1, well summarised Adrian!
>>
>> Jacques
>>
>>
>> Le 20/04/2015 12:39, Adrian Crum a écrit :
>>
>>> That's the point I was trying to make. Our needs in this project are
>>> pretty basic, and Subversion handles those needs well. Git will merely make
>>> things unnecessarily complicated.
>>>
>>> At ApacheCon, the motivations for switching to Git were not related to
>>> OFBiz project management, but were related to local management of
>>> OFBiz-based projects. The common complaint was connecting local Git
>>> repositories to the project's Subversion repository. So, switching the
>>> project to Git will make life easier for some.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>> On 4/20/2015 11:31 AM, Pierre Smits wrote:
>>>
>>>> I am also familiar with Git.
>>>>
>>>> Please don't project your uncertainties regarding the expertise and
>>>> experiences of other as their traits. And don't confuse advancement with
>>>> suitability. A rocket ship is more advanced than a bike. But that doesn't
>>>> mean it is suitable for more than just hauling stuff into space.
>>>>
>>>> Best regards,
>>>>
>>>> Pierre Smits
>>>>
>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>> Services & Solutions for Cloud-
>>>> Based Manufacturing, Professional
>>>> Services and Retail & Trade
>>>> http://www.orrtiz.com
>>>>
>>>> On Mon, Apr 20, 2015 at 12:19 PM, Adrian Crum <
>>>> adrian.crum@sandglass-software.com> wrote:
>>>>
>>>> I am thoroughly familiar with Git. I've used it on on three projects,
>>>>> and
>>>>> that is why I don't like it.
>>>>>
>>>>> I have a far easier time merging branches with Subversion. Git always
>>>>> screws things up.
>>>>>
>>>>> I don't need to be convinced of anything. I have my experience and my
>>>>> opinion. But still, I'm not opposed to switching to Git.
>>>>>
>>>>> Adrian Crum
>>>>> Sandglass Software
>>>>> www.sandglass-software.com
>>>>>
>>>>> On 4/20/2015 11:08 AM, Taher Alkhateeb wrote:
>>>>>
>>>>> One of the most difficult and challenging issue with branches is
>>>>>> _merging_
>>>>>> them. Git is a tool that is far more advanced in its feature set in
>>>>>> that
>>>>>> area.
>>>>>>
>>>>>> It seems some of the opinions expressed against git are due to
>>>>>> unfamiliarity. The only way to be convinced is to try it on an advanced
>>>>>> level as i don't think an email thread would be enough for convincing
>>>>>> anyone of the merits.
>>>>>>
>>>>>> My 2 cents
>>>>>>
>>>>>> Taher Alkhateeb
>>>>>> On Apr 20, 2015 12:54 PM, "Pierre Smits" <pi...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> If we only want GIT for multiple local development branches, then we
>>>>>> are
>>>>>>
>>>>>>> doing for the wrong reasons. SVN doesn't hinder you in doing that
>>>>>>> today.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Pierre Smits
>>>>>>>
>>>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>>>> Services & Solutions for Cloud-
>>>>>>> Based Manufacturing, Professional
>>>>>>> Services and Retail & Trade
>>>>>>> http://www.orrtiz.com
>>>>>>>
>>>>>>> On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux <
>>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>>
>>>>>>> Like Adrian and mostly for the same reasons, I don't believe we need
>>>>>>>
>>>>>>>> Git.
>>>>>>>>
>>>>>>>> But there is one other major reason which has already been discussed
>>>>>>>> in
>>>>>>>> the other common ASF MLs. As Taher exulted, it's possible to create
>>>>>>>>
>>>>>>>> local
>>>>>>> branches. So people are able to do a lot of work alone without
>>>>>>>> exchanging
>>>>>>>> before committing or submitting. It will certainly not help to have
>>>>>>>> this
>>>>>>>> possibility. Remember our recent discussion on the lack or core
>>>>>>>> commits
>>>>>>>> reviews. With Git you end with commits bursts or big patches and it's
>>>>>>>>
>>>>>>>> then
>>>>>>> hard to review and too late to share ideas.
>>>>>>>> So unlike Adrian, I'm even strongly against it. I will not hesitate
>>>>>>>> to
>>>>>>>>
>>>>>>>> use
>>>>>>> a -1 if necessary!
>>>>>>>> Jacques
>>>>>>>>
>>>>>>>>
>>>>>>>> Le 20/04/2015 09:53, Adrian Crum a écrit :
>>>>>>>>
>>>>>>>> I don't agree that "all major contributors are using git."
>>>>>>>>
>>>>>>>>> Personally, I find Git to be an overly complicated solution to a
>>>>>>>>> simple
>>>>>>>>> problem. It frequently does bizarre things that no one understands,
>>>>>>>>> and
>>>>>>>>>
>>>>>>>>> you
>>>>>>> are left with things being mysteriously reverted for unknown reasons.
>>>>>>>>> This isn't a -1 vote though. I'm just making it clear that I will be
>>>>>>>>> dragged kicking and screaming into using it.
>>>>>>>>>
>>>>>>>>> Adrian Crum
>>>>>>>>> Sandglass Software
>>>>>>>>> www.sandglass-software.com
>>>>>>>>>
>>>>>>>>> On 4/20/2015 5:38 AM, Hans Bakker wrote:
>>>>>>>>>
>>>>>>>>> As discussed at apachecon in Austin, i propose to switch from svn
>>>>>>>>> to
>>>>>>>>>
>>>>>>>>>> git
>>>>>>> for the ofbiz repository. The main reason being that all major
>>>>>>>>> contributors are using git and contributions are cumbersome,
>>>>>>>>>> further,
>>>>>>>>>> git allows for better branching and merging.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Hans
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
Re: move to git.
Posted by Pierre Smits <pi...@gmail.com>.
@Jacques: is your +1 to be regarded as a yes vote fore moving to git? I am
getting confused somehow.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Mon, Apr 20, 2015 at 1:01 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> +1, well summarised Adrian!
>
> Jacques
>
>
> Le 20/04/2015 12:39, Adrian Crum a écrit :
>
>> That's the point I was trying to make. Our needs in this project are
>> pretty basic, and Subversion handles those needs well. Git will merely make
>> things unnecessarily complicated.
>>
>> At ApacheCon, the motivations for switching to Git were not related to
>> OFBiz project management, but were related to local management of
>> OFBiz-based projects. The common complaint was connecting local Git
>> repositories to the project's Subversion repository. So, switching the
>> project to Git will make life easier for some.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 4/20/2015 11:31 AM, Pierre Smits wrote:
>>
>>> I am also familiar with Git.
>>>
>>> Please don't project your uncertainties regarding the expertise and
>>> experiences of other as their traits. And don't confuse advancement with
>>> suitability. A rocket ship is more advanced than a bike. But that doesn't
>>> mean it is suitable for more than just hauling stuff into space.
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Mon, Apr 20, 2015 at 12:19 PM, Adrian Crum <
>>> adrian.crum@sandglass-software.com> wrote:
>>>
>>> I am thoroughly familiar with Git. I've used it on on three projects,
>>>> and
>>>> that is why I don't like it.
>>>>
>>>> I have a far easier time merging branches with Subversion. Git always
>>>> screws things up.
>>>>
>>>> I don't need to be convinced of anything. I have my experience and my
>>>> opinion. But still, I'm not opposed to switching to Git.
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 4/20/2015 11:08 AM, Taher Alkhateeb wrote:
>>>>
>>>> One of the most difficult and challenging issue with branches is
>>>>> _merging_
>>>>> them. Git is a tool that is far more advanced in its feature set in
>>>>> that
>>>>> area.
>>>>>
>>>>> It seems some of the opinions expressed against git are due to
>>>>> unfamiliarity. The only way to be convinced is to try it on an advanced
>>>>> level as i don't think an email thread would be enough for convincing
>>>>> anyone of the merits.
>>>>>
>>>>> My 2 cents
>>>>>
>>>>> Taher Alkhateeb
>>>>> On Apr 20, 2015 12:54 PM, "Pierre Smits" <pi...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> If we only want GIT for multiple local development branches, then we
>>>>> are
>>>>>
>>>>>> doing for the wrong reasons. SVN doesn't hinder you in doing that
>>>>>> today.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Pierre Smits
>>>>>>
>>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>>> Services & Solutions for Cloud-
>>>>>> Based Manufacturing, Professional
>>>>>> Services and Retail & Trade
>>>>>> http://www.orrtiz.com
>>>>>>
>>>>>> On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux <
>>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>>
>>>>>> Like Adrian and mostly for the same reasons, I don't believe we need
>>>>>>
>>>>>>> Git.
>>>>>>>
>>>>>>> But there is one other major reason which has already been discussed
>>>>>>> in
>>>>>>> the other common ASF MLs. As Taher exulted, it's possible to create
>>>>>>>
>>>>>>> local
>>>>>>
>>>>>> branches. So people are able to do a lot of work alone without
>>>>>>> exchanging
>>>>>>> before committing or submitting. It will certainly not help to have
>>>>>>> this
>>>>>>> possibility. Remember our recent discussion on the lack or core
>>>>>>> commits
>>>>>>> reviews. With Git you end with commits bursts or big patches and it's
>>>>>>>
>>>>>>> then
>>>>>>
>>>>>> hard to review and too late to share ideas.
>>>>>>>
>>>>>>> So unlike Adrian, I'm even strongly against it. I will not hesitate
>>>>>>> to
>>>>>>>
>>>>>>> use
>>>>>>
>>>>>> a -1 if necessary!
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>> Le 20/04/2015 09:53, Adrian Crum a écrit :
>>>>>>>
>>>>>>> I don't agree that "all major contributors are using git."
>>>>>>>
>>>>>>>>
>>>>>>>> Personally, I find Git to be an overly complicated solution to a
>>>>>>>> simple
>>>>>>>> problem. It frequently does bizarre things that no one understands,
>>>>>>>> and
>>>>>>>>
>>>>>>>> you
>>>>>>>
>>>>>>
>>>>>> are left with things being mysteriously reverted for unknown reasons.
>>>>>>>
>>>>>>>>
>>>>>>>> This isn't a -1 vote though. I'm just making it clear that I will be
>>>>>>>> dragged kicking and screaming into using it.
>>>>>>>>
>>>>>>>> Adrian Crum
>>>>>>>> Sandglass Software
>>>>>>>> www.sandglass-software.com
>>>>>>>>
>>>>>>>> On 4/20/2015 5:38 AM, Hans Bakker wrote:
>>>>>>>>
>>>>>>>> As discussed at apachecon in Austin, i propose to switch from svn
>>>>>>>> to
>>>>>>>>
>>>>>>>>>
>>>>>>>>> git
>>>>>>>>
>>>>>>>
>>>>>> for the ofbiz repository. The main reason being that all major
>>>>>>>
>>>>>>>> contributors are using git and contributions are cumbersome,
>>>>>>>>> further,
>>>>>>>>> git allows for better branching and merging.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Hans
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>
>>
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
+1, well summarised Adrian!
Jacques
Le 20/04/2015 12:39, Adrian Crum a écrit :
> That's the point I was trying to make. Our needs in this project are pretty basic, and Subversion handles those needs well. Git will merely make
> things unnecessarily complicated.
>
> At ApacheCon, the motivations for switching to Git were not related to OFBiz project management, but were related to local management of OFBiz-based
> projects. The common complaint was connecting local Git repositories to the project's Subversion repository. So, switching the project to Git will
> make life easier for some.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 4/20/2015 11:31 AM, Pierre Smits wrote:
>> I am also familiar with Git.
>>
>> Please don't project your uncertainties regarding the expertise and
>> experiences of other as their traits. And don't confuse advancement with
>> suitability. A rocket ship is more advanced than a bike. But that doesn't
>> mean it is suitable for more than just hauling stuff into space.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Mon, Apr 20, 2015 at 12:19 PM, Adrian Crum <
>> adrian.crum@sandglass-software.com> wrote:
>>
>>> I am thoroughly familiar with Git. I've used it on on three projects, and
>>> that is why I don't like it.
>>>
>>> I have a far easier time merging branches with Subversion. Git always
>>> screws things up.
>>>
>>> I don't need to be convinced of anything. I have my experience and my
>>> opinion. But still, I'm not opposed to switching to Git.
>>>
>>> Adrian Crum
>>> Sandglass Software
>>> www.sandglass-software.com
>>>
>>> On 4/20/2015 11:08 AM, Taher Alkhateeb wrote:
>>>
>>>> One of the most difficult and challenging issue with branches is _merging_
>>>> them. Git is a tool that is far more advanced in its feature set in that
>>>> area.
>>>>
>>>> It seems some of the opinions expressed against git are due to
>>>> unfamiliarity. The only way to be convinced is to try it on an advanced
>>>> level as i don't think an email thread would be enough for convincing
>>>> anyone of the merits.
>>>>
>>>> My 2 cents
>>>>
>>>> Taher Alkhateeb
>>>> On Apr 20, 2015 12:54 PM, "Pierre Smits" <pi...@gmail.com> wrote:
>>>>
>>>> If we only want GIT for multiple local development branches, then we are
>>>>> doing for the wrong reasons. SVN doesn't hinder you in doing that today.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Pierre Smits
>>>>>
>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>> Services & Solutions for Cloud-
>>>>> Based Manufacturing, Professional
>>>>> Services and Retail & Trade
>>>>> http://www.orrtiz.com
>>>>>
>>>>> On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux <
>>>>> jacques.le.roux@les7arts.com> wrote:
>>>>>
>>>>> Like Adrian and mostly for the same reasons, I don't believe we need
>>>>>> Git.
>>>>>>
>>>>>> But there is one other major reason which has already been discussed in
>>>>>> the other common ASF MLs. As Taher exulted, it's possible to create
>>>>>>
>>>>> local
>>>>>
>>>>>> branches. So people are able to do a lot of work alone without
>>>>>> exchanging
>>>>>> before committing or submitting. It will certainly not help to have this
>>>>>> possibility. Remember our recent discussion on the lack or core commits
>>>>>> reviews. With Git you end with commits bursts or big patches and it's
>>>>>>
>>>>> then
>>>>>
>>>>>> hard to review and too late to share ideas.
>>>>>>
>>>>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>>>>>>
>>>>> use
>>>>>
>>>>>> a -1 if necessary!
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>> Le 20/04/2015 09:53, Adrian Crum a écrit :
>>>>>>
>>>>>> I don't agree that "all major contributors are using git."
>>>>>>>
>>>>>>> Personally, I find Git to be an overly complicated solution to a simple
>>>>>>> problem. It frequently does bizarre things that no one understands, and
>>>>>>>
>>>>>> you
>>>>>
>>>>>> are left with things being mysteriously reverted for unknown reasons.
>>>>>>>
>>>>>>> This isn't a -1 vote though. I'm just making it clear that I will be
>>>>>>> dragged kicking and screaming into using it.
>>>>>>>
>>>>>>> Adrian Crum
>>>>>>> Sandglass Software
>>>>>>> www.sandglass-software.com
>>>>>>>
>>>>>>> On 4/20/2015 5:38 AM, Hans Bakker wrote:
>>>>>>>
>>>>>>> As discussed at apachecon in Austin, i propose to switch from svn to
>>>>>>>>
>>>>>>> git
>>>>>
>>>>>> for the ofbiz repository. The main reason being that all major
>>>>>>>> contributors are using git and contributions are cumbersome, further,
>>>>>>>> git allows for better branching and merging.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Hans
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>
>
Re: move to git.
Posted by Adrian Crum <ad...@sandglass-software.com>.
That's the point I was trying to make. Our needs in this project are
pretty basic, and Subversion handles those needs well. Git will merely
make things unnecessarily complicated.
At ApacheCon, the motivations for switching to Git were not related to
OFBiz project management, but were related to local management of
OFBiz-based projects. The common complaint was connecting local Git
repositories to the project's Subversion repository. So, switching the
project to Git will make life easier for some.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 4/20/2015 11:31 AM, Pierre Smits wrote:
> I am also familiar with Git.
>
> Please don't project your uncertainties regarding the expertise and
> experiences of other as their traits. And don't confuse advancement with
> suitability. A rocket ship is more advanced than a bike. But that doesn't
> mean it is suitable for more than just hauling stuff into space.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Mon, Apr 20, 2015 at 12:19 PM, Adrian Crum <
> adrian.crum@sandglass-software.com> wrote:
>
>> I am thoroughly familiar with Git. I've used it on on three projects, and
>> that is why I don't like it.
>>
>> I have a far easier time merging branches with Subversion. Git always
>> screws things up.
>>
>> I don't need to be convinced of anything. I have my experience and my
>> opinion. But still, I'm not opposed to switching to Git.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 4/20/2015 11:08 AM, Taher Alkhateeb wrote:
>>
>>> One of the most difficult and challenging issue with branches is _merging_
>>> them. Git is a tool that is far more advanced in its feature set in that
>>> area.
>>>
>>> It seems some of the opinions expressed against git are due to
>>> unfamiliarity. The only way to be convinced is to try it on an advanced
>>> level as i don't think an email thread would be enough for convincing
>>> anyone of the merits.
>>>
>>> My 2 cents
>>>
>>> Taher Alkhateeb
>>> On Apr 20, 2015 12:54 PM, "Pierre Smits" <pi...@gmail.com> wrote:
>>>
>>> If we only want GIT for multiple local development branches, then we are
>>>> doing for the wrong reasons. SVN doesn't hinder you in doing that today.
>>>>
>>>> Best regards,
>>>>
>>>> Pierre Smits
>>>>
>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>> Services & Solutions for Cloud-
>>>> Based Manufacturing, Professional
>>>> Services and Retail & Trade
>>>> http://www.orrtiz.com
>>>>
>>>> On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux <
>>>> jacques.le.roux@les7arts.com> wrote:
>>>>
>>>> Like Adrian and mostly for the same reasons, I don't believe we need
>>>>> Git.
>>>>>
>>>>> But there is one other major reason which has already been discussed in
>>>>> the other common ASF MLs. As Taher exulted, it's possible to create
>>>>>
>>>> local
>>>>
>>>>> branches. So people are able to do a lot of work alone without
>>>>> exchanging
>>>>> before committing or submitting. It will certainly not help to have this
>>>>> possibility. Remember our recent discussion on the lack or core commits
>>>>> reviews. With Git you end with commits bursts or big patches and it's
>>>>>
>>>> then
>>>>
>>>>> hard to review and too late to share ideas.
>>>>>
>>>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>>>>>
>>>> use
>>>>
>>>>> a -1 if necessary!
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>> Le 20/04/2015 09:53, Adrian Crum a écrit :
>>>>>
>>>>> I don't agree that "all major contributors are using git."
>>>>>>
>>>>>> Personally, I find Git to be an overly complicated solution to a simple
>>>>>> problem. It frequently does bizarre things that no one understands, and
>>>>>>
>>>>> you
>>>>
>>>>> are left with things being mysteriously reverted for unknown reasons.
>>>>>>
>>>>>> This isn't a -1 vote though. I'm just making it clear that I will be
>>>>>> dragged kicking and screaming into using it.
>>>>>>
>>>>>> Adrian Crum
>>>>>> Sandglass Software
>>>>>> www.sandglass-software.com
>>>>>>
>>>>>> On 4/20/2015 5:38 AM, Hans Bakker wrote:
>>>>>>
>>>>>> As discussed at apachecon in Austin, i propose to switch from svn to
>>>>>>>
>>>>>> git
>>>>
>>>>> for the ofbiz repository. The main reason being that all major
>>>>>>> contributors are using git and contributions are cumbersome, further,
>>>>>>> git allows for better branching and merging.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Hans
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>
Re: move to git.
Posted by Pierre Smits <pi...@gmail.com>.
I am also familiar with Git.
Please don't project your uncertainties regarding the expertise and
experiences of other as their traits. And don't confuse advancement with
suitability. A rocket ship is more advanced than a bike. But that doesn't
mean it is suitable for more than just hauling stuff into space.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Mon, Apr 20, 2015 at 12:19 PM, Adrian Crum <
adrian.crum@sandglass-software.com> wrote:
> I am thoroughly familiar with Git. I've used it on on three projects, and
> that is why I don't like it.
>
> I have a far easier time merging branches with Subversion. Git always
> screws things up.
>
> I don't need to be convinced of anything. I have my experience and my
> opinion. But still, I'm not opposed to switching to Git.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 4/20/2015 11:08 AM, Taher Alkhateeb wrote:
>
>> One of the most difficult and challenging issue with branches is _merging_
>> them. Git is a tool that is far more advanced in its feature set in that
>> area.
>>
>> It seems some of the opinions expressed against git are due to
>> unfamiliarity. The only way to be convinced is to try it on an advanced
>> level as i don't think an email thread would be enough for convincing
>> anyone of the merits.
>>
>> My 2 cents
>>
>> Taher Alkhateeb
>> On Apr 20, 2015 12:54 PM, "Pierre Smits" <pi...@gmail.com> wrote:
>>
>> If we only want GIT for multiple local development branches, then we are
>>> doing for the wrong reasons. SVN doesn't hinder you in doing that today.
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux <
>>> jacques.le.roux@les7arts.com> wrote:
>>>
>>> Like Adrian and mostly for the same reasons, I don't believe we need
>>>> Git.
>>>>
>>>> But there is one other major reason which has already been discussed in
>>>> the other common ASF MLs. As Taher exulted, it's possible to create
>>>>
>>> local
>>>
>>>> branches. So people are able to do a lot of work alone without
>>>> exchanging
>>>> before committing or submitting. It will certainly not help to have this
>>>> possibility. Remember our recent discussion on the lack or core commits
>>>> reviews. With Git you end with commits bursts or big patches and it's
>>>>
>>> then
>>>
>>>> hard to review and too late to share ideas.
>>>>
>>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>>>>
>>> use
>>>
>>>> a -1 if necessary!
>>>>
>>>> Jacques
>>>>
>>>>
>>>> Le 20/04/2015 09:53, Adrian Crum a écrit :
>>>>
>>>> I don't agree that "all major contributors are using git."
>>>>>
>>>>> Personally, I find Git to be an overly complicated solution to a simple
>>>>> problem. It frequently does bizarre things that no one understands, and
>>>>>
>>>> you
>>>
>>>> are left with things being mysteriously reverted for unknown reasons.
>>>>>
>>>>> This isn't a -1 vote though. I'm just making it clear that I will be
>>>>> dragged kicking and screaming into using it.
>>>>>
>>>>> Adrian Crum
>>>>> Sandglass Software
>>>>> www.sandglass-software.com
>>>>>
>>>>> On 4/20/2015 5:38 AM, Hans Bakker wrote:
>>>>>
>>>>> As discussed at apachecon in Austin, i propose to switch from svn to
>>>>>>
>>>>> git
>>>
>>>> for the ofbiz repository. The main reason being that all major
>>>>>> contributors are using git and contributions are cumbersome, further,
>>>>>> git allows for better branching and merging.
>>>>>>
>>>>>> Regards,
>>>>>> Hans
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>
Re: move to git.
Posted by Adrian Crum <ad...@sandglass-software.com>.
I am thoroughly familiar with Git. I've used it on on three projects,
and that is why I don't like it.
I have a far easier time merging branches with Subversion. Git always
screws things up.
I don't need to be convinced of anything. I have my experience and my
opinion. But still, I'm not opposed to switching to Git.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 4/20/2015 11:08 AM, Taher Alkhateeb wrote:
> One of the most difficult and challenging issue with branches is _merging_
> them. Git is a tool that is far more advanced in its feature set in that
> area.
>
> It seems some of the opinions expressed against git are due to
> unfamiliarity. The only way to be convinced is to try it on an advanced
> level as i don't think an email thread would be enough for convincing
> anyone of the merits.
>
> My 2 cents
>
> Taher Alkhateeb
> On Apr 20, 2015 12:54 PM, "Pierre Smits" <pi...@gmail.com> wrote:
>
>> If we only want GIT for multiple local development branches, then we are
>> doing for the wrong reasons. SVN doesn't hinder you in doing that today.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>>> Like Adrian and mostly for the same reasons, I don't believe we need Git.
>>>
>>> But there is one other major reason which has already been discussed in
>>> the other common ASF MLs. As Taher exulted, it's possible to create
>> local
>>> branches. So people are able to do a lot of work alone without exchanging
>>> before committing or submitting. It will certainly not help to have this
>>> possibility. Remember our recent discussion on the lack or core commits
>>> reviews. With Git you end with commits bursts or big patches and it's
>> then
>>> hard to review and too late to share ideas.
>>>
>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>> use
>>> a -1 if necessary!
>>>
>>> Jacques
>>>
>>>
>>> Le 20/04/2015 09:53, Adrian Crum a écrit :
>>>
>>>> I don't agree that "all major contributors are using git."
>>>>
>>>> Personally, I find Git to be an overly complicated solution to a simple
>>>> problem. It frequently does bizarre things that no one understands, and
>> you
>>>> are left with things being mysteriously reverted for unknown reasons.
>>>>
>>>> This isn't a -1 vote though. I'm just making it clear that I will be
>>>> dragged kicking and screaming into using it.
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 4/20/2015 5:38 AM, Hans Bakker wrote:
>>>>
>>>>> As discussed at apachecon in Austin, i propose to switch from svn to
>> git
>>>>> for the ofbiz repository. The main reason being that all major
>>>>> contributors are using git and contributions are cumbersome, further,
>>>>> git allows for better branching and merging.
>>>>>
>>>>> Regards,
>>>>> Hans
>>>>>
>>>>
>>>>
>>
>
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
I have used Git on a project last year for 9 months, enough to get an idea I believe.
I don't say it's bad by itself, I say it's bad for the community
Jacques
Le 20/04/2015 12:08, Taher Alkhateeb a écrit :
> One of the most difficult and challenging issue with branches is _merging_
> them. Git is a tool that is far more advanced in its feature set in that
> area.
>
> It seems some of the opinions expressed against git are due to
> unfamiliarity. The only way to be convinced is to try it on an advanced
> level as i don't think an email thread would be enough for convincing
> anyone of the merits.
>
> My 2 cents
>
> Taher Alkhateeb
> On Apr 20, 2015 12:54 PM, "Pierre Smits" <pi...@gmail.com> wrote:
>
>> If we only want GIT for multiple local development branches, then we are
>> doing for the wrong reasons. SVN doesn't hinder you in doing that today.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>>> Like Adrian and mostly for the same reasons, I don't believe we need Git.
>>>
>>> But there is one other major reason which has already been discussed in
>>> the other common ASF MLs. As Taher exulted, it's possible to create
>> local
>>> branches. So people are able to do a lot of work alone without exchanging
>>> before committing or submitting. It will certainly not help to have this
>>> possibility. Remember our recent discussion on the lack or core commits
>>> reviews. With Git you end with commits bursts or big patches and it's
>> then
>>> hard to review and too late to share ideas.
>>>
>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>> use
>>> a -1 if necessary!
>>>
>>> Jacques
>>>
>>>
>>> Le 20/04/2015 09:53, Adrian Crum a écrit :
>>>
>>>> I don't agree that "all major contributors are using git."
>>>>
>>>> Personally, I find Git to be an overly complicated solution to a simple
>>>> problem. It frequently does bizarre things that no one understands, and
>> you
>>>> are left with things being mysteriously reverted for unknown reasons.
>>>>
>>>> This isn't a -1 vote though. I'm just making it clear that I will be
>>>> dragged kicking and screaming into using it.
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 4/20/2015 5:38 AM, Hans Bakker wrote:
>>>>
>>>>> As discussed at apachecon in Austin, i propose to switch from svn to
>> git
>>>>> for the ofbiz repository. The main reason being that all major
>>>>> contributors are using git and contributions are cumbersome, further,
>>>>> git allows for better branching and merging.
>>>>>
>>>>> Regards,
>>>>> Hans
>>>>>
>>>>
Re: move to git.
Posted by Taher Alkhateeb <sl...@gmail.com>.
One of the most difficult and challenging issue with branches is _merging_
them. Git is a tool that is far more advanced in its feature set in that
area.
It seems some of the opinions expressed against git are due to
unfamiliarity. The only way to be convinced is to try it on an advanced
level as i don't think an email thread would be enough for convincing
anyone of the merits.
My 2 cents
Taher Alkhateeb
On Apr 20, 2015 12:54 PM, "Pierre Smits" <pi...@gmail.com> wrote:
> If we only want GIT for multiple local development branches, then we are
> doing for the wrong reasons. SVN doesn't hinder you in doing that today.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
> > Like Adrian and mostly for the same reasons, I don't believe we need Git.
> >
> > But there is one other major reason which has already been discussed in
> > the other common ASF MLs. As Taher exulted, it's possible to create
> local
> > branches. So people are able to do a lot of work alone without exchanging
> > before committing or submitting. It will certainly not help to have this
> > possibility. Remember our recent discussion on the lack or core commits
> > reviews. With Git you end with commits bursts or big patches and it's
> then
> > hard to review and too late to share ideas.
> >
> > So unlike Adrian, I'm even strongly against it. I will not hesitate to
> use
> > a -1 if necessary!
> >
> > Jacques
> >
> >
> > Le 20/04/2015 09:53, Adrian Crum a écrit :
> >
> >> I don't agree that "all major contributors are using git."
> >>
> >> Personally, I find Git to be an overly complicated solution to a simple
> >> problem. It frequently does bizarre things that no one understands, and
> you
> >> are left with things being mysteriously reverted for unknown reasons.
> >>
> >> This isn't a -1 vote though. I'm just making it clear that I will be
> >> dragged kicking and screaming into using it.
> >>
> >> Adrian Crum
> >> Sandglass Software
> >> www.sandglass-software.com
> >>
> >> On 4/20/2015 5:38 AM, Hans Bakker wrote:
> >>
> >>> As discussed at apachecon in Austin, i propose to switch from svn to
> git
> >>> for the ofbiz repository. The main reason being that all major
> >>> contributors are using git and contributions are cumbersome, further,
> >>> git allows for better branching and merging.
> >>>
> >>> Regards,
> >>> Hans
> >>>
> >>
> >>
>
Re: move to git.
Posted by Christian Carlow <ch...@gmail.com>.
Thanks for clarifying Jacques,
I switched to git a few weeks ago because it allows non-committers like
myself to develop as if having svn committer privilege. Having the
ability to create and switch between branches for my JIRA issues was
very liberating and convenient for generating patches. If svn cannot
provide non-committers the same freedom then the git switch seems more
worthy.
On Mon, 2015-04-20 at 20:55 +0200, Jacques Le Roux wrote:
> Le 20/04/2015 20:37, Christian Carlow a écrit :
> > SVN allows for a local branching? Believing git only allows this was
> > the main reason for my recent switch. Are commit privileges not
> > necessary for the creation of such an svn branch as is the case with
> > git?
>
> No, clearly Git allows more than Svn (both cases above for instance), but it does not mean that its the solution for OFBiz
>
> Note that you have also OFBiz at https://github.com/apache/ofbiz if you need local branching...
>
> Jacques
>
>
> >
> > On Mon, 2015-04-20 at 11:54 +0200, Pierre Smits wrote:
> >> If we only want GIT for multiple local development branches, then we are
> >> doing for the wrong reasons. SVN doesn't hinder you in doing that today.
> >>
> >> Best regards,
> >>
> >> Pierre Smits
> >>
> >> *ORRTIZ.COM <http://www.orrtiz.com>*
> >> Services & Solutions for Cloud-
> >> Based Manufacturing, Professional
> >> Services and Retail & Trade
> >> http://www.orrtiz.com
> >>
> >> On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux <
> >> jacques.le.roux@les7arts.com> wrote:
> >>
> >>> Like Adrian and mostly for the same reasons, I don't believe we need Git.
> >>>
> >>> But there is one other major reason which has already been discussed in
> >>> the other common ASF MLs. As Taher exulted, it's possible to create local
> >>> branches. So people are able to do a lot of work alone without exchanging
> >>> before committing or submitting. It will certainly not help to have this
> >>> possibility. Remember our recent discussion on the lack or core commits
> >>> reviews. With Git you end with commits bursts or big patches and it's then
> >>> hard to review and too late to share ideas.
> >>>
> >>> So unlike Adrian, I'm even strongly against it. I will not hesitate to use
> >>> a -1 if necessary!
> >>>
> >>> Jacques
> >>>
> >>>
> >>> Le 20/04/2015 09:53, Adrian Crum a écrit :
> >>>
> >>>> I don't agree that "all major contributors are using git."
> >>>>
> >>>> Personally, I find Git to be an overly complicated solution to a simple
> >>>> problem. It frequently does bizarre things that no one understands, and you
> >>>> are left with things being mysteriously reverted for unknown reasons.
> >>>>
> >>>> This isn't a -1 vote though. I'm just making it clear that I will be
> >>>> dragged kicking and screaming into using it.
> >>>>
> >>>> Adrian Crum
> >>>> Sandglass Software
> >>>> www.sandglass-software.com
> >>>>
> >>>> On 4/20/2015 5:38 AM, Hans Bakker wrote:
> >>>>
> >>>>> As discussed at apachecon in Austin, i propose to switch from svn to git
> >>>>> for the ofbiz repository. The main reason being that all major
> >>>>> contributors are using git and contributions are cumbersome, further,
> >>>>> git allows for better branching and merging.
> >>>>>
> >>>>> Regards,
> >>>>> Hans
> >>>>>
> >>>>
> >
> >
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 20/04/2015 20:37, Christian Carlow a écrit :
> SVN allows for a local branching? Believing git only allows this was
> the main reason for my recent switch. Are commit privileges not
> necessary for the creation of such an svn branch as is the case with
> git?
No, clearly Git allows more than Svn (both cases above for instance), but it does not mean that its the solution for OFBiz
Note that you have also OFBiz at https://github.com/apache/ofbiz if you need local branching...
Jacques
>
> On Mon, 2015-04-20 at 11:54 +0200, Pierre Smits wrote:
>> If we only want GIT for multiple local development branches, then we are
>> doing for the wrong reasons. SVN doesn't hinder you in doing that today.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>>> Like Adrian and mostly for the same reasons, I don't believe we need Git.
>>>
>>> But there is one other major reason which has already been discussed in
>>> the other common ASF MLs. As Taher exulted, it's possible to create local
>>> branches. So people are able to do a lot of work alone without exchanging
>>> before committing or submitting. It will certainly not help to have this
>>> possibility. Remember our recent discussion on the lack or core commits
>>> reviews. With Git you end with commits bursts or big patches and it's then
>>> hard to review and too late to share ideas.
>>>
>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to use
>>> a -1 if necessary!
>>>
>>> Jacques
>>>
>>>
>>> Le 20/04/2015 09:53, Adrian Crum a écrit :
>>>
>>>> I don't agree that "all major contributors are using git."
>>>>
>>>> Personally, I find Git to be an overly complicated solution to a simple
>>>> problem. It frequently does bizarre things that no one understands, and you
>>>> are left with things being mysteriously reverted for unknown reasons.
>>>>
>>>> This isn't a -1 vote though. I'm just making it clear that I will be
>>>> dragged kicking and screaming into using it.
>>>>
>>>> Adrian Crum
>>>> Sandglass Software
>>>> www.sandglass-software.com
>>>>
>>>> On 4/20/2015 5:38 AM, Hans Bakker wrote:
>>>>
>>>>> As discussed at apachecon in Austin, i propose to switch from svn to git
>>>>> for the ofbiz repository. The main reason being that all major
>>>>> contributors are using git and contributions are cumbersome, further,
>>>>> git allows for better branching and merging.
>>>>>
>>>>> Regards,
>>>>> Hans
>>>>>
>>>>
>
>
Re: move to git.
Posted by Christian Carlow <ch...@gmail.com>.
As always, thanks for the feedback ;)
On Mon, 2015-04-20 at 23:07 +0200, Pierre Smits wrote:
> Thanks for what, Christian?
>
> Ah.... It seems you're misunderstanding me as I might have been a bit to
> brief. I have commit privileges in other projects. I don't have that
> privilege in this project.
>
> By the way, I have seen your recent git coalescence/aggregation regarding
> various issues into one big-sized patch. Affecting multiple components.
> This is, I surmise, the result of the way Git is utilised as a change
> integration tool from various private development branches before
> submitting patches/promoted. Which is a bit harder to achieve in SVN.
>
> At the moment I am not certain whether to llike or dislike the end result
> (the patch in question).
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Mon, Apr 20, 2015 at 10:26 PM, Christian Carlow <
> christian.carlow@gmail.com> wrote:
>
> > Thanks Pierre,
> >
> > I switched to git because committer privileges don't have to be granted
> > before non-committers have access to development freedoms such as branch
> > creations for conveniencies such as patch creation. Such a system seems
> > to promote more open source collaboration.
> >
> > On Mon, 2015-04-20 at 21:49 +0200, Pierre Smits wrote:
> > > I have currently multiple local development branches in our SVN and they
> > > are SVN based and they are all of the same bases at
> > > https://svn.apache.org/repos/asf/ofbiz.
> > >
> > > And yes, I have commit privileges.
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > *ORRTIZ.COM <http://www.orrtiz.com>*
> > > Services & Solutions for Cloud-
> > > Based Manufacturing, Professional
> > > Services and Retail & Trade
> > > http://www.orrtiz.com
> > >
> > > On Mon, Apr 20, 2015 at 8:37 PM, Christian Carlow <
> > > christian.carlow@gmail.com> wrote:
> > >
> > > > SVN allows for a local branching? Believing git only allows this was
> > > > the main reason for my recent switch. Are commit privileges not
> > > > necessary for the creation of such an svn branch as is the case with
> > > > git?
> > > >
> > > > On Mon, 2015-04-20 at 11:54 +0200, Pierre Smits wrote:
> > > > > If we only want GIT for multiple local development branches, then we
> > are
> > > > > doing for the wrong reasons. SVN doesn't hinder you in doing that
> > today.
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Pierre Smits
> > > > >
> > > > > *ORRTIZ.COM <http://www.orrtiz.com>*
> > > > > Services & Solutions for Cloud-
> > > > > Based Manufacturing, Professional
> > > > > Services and Retail & Trade
> > > > > http://www.orrtiz.com
> > > > >
> > > > > On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux <
> > > > > jacques.le.roux@les7arts.com> wrote:
> > > > >
> > > > > > Like Adrian and mostly for the same reasons, I don't believe we
> > need
> > > > Git.
> > > > > >
> > > > > > But there is one other major reason which has already been
> > discussed in
> > > > > > the other common ASF MLs. As Taher exulted, it's possible to
> > create
> > > > local
> > > > > > branches. So people are able to do a lot of work alone without
> > > > exchanging
> > > > > > before committing or submitting. It will certainly not help to have
> > > > this
> > > > > > possibility. Remember our recent discussion on the lack or core
> > commits
> > > > > > reviews. With Git you end with commits bursts or big patches and
> > it's
> > > > then
> > > > > > hard to review and too late to share ideas.
> > > > > >
> > > > > > So unlike Adrian, I'm even strongly against it. I will not
> > hesitate to
> > > > use
> > > > > > a -1 if necessary!
> > > > > >
> > > > > > Jacques
> > > > > >
> > > > > >
> > > > > > Le 20/04/2015 09:53, Adrian Crum a écrit :
> > > > > >
> > > > > >> I don't agree that "all major contributors are using git."
> > > > > >>
> > > > > >> Personally, I find Git to be an overly complicated solution to a
> > > > simple
> > > > > >> problem. It frequently does bizarre things that no one
> > understands,
> > > > and you
> > > > > >> are left with things being mysteriously reverted for unknown
> > reasons.
> > > > > >>
> > > > > >> This isn't a -1 vote though. I'm just making it clear that I will
> > be
> > > > > >> dragged kicking and screaming into using it.
> > > > > >>
> > > > > >> Adrian Crum
> > > > > >> Sandglass Software
> > > > > >> www.sandglass-software.com
> > > > > >>
> > > > > >> On 4/20/2015 5:38 AM, Hans Bakker wrote:
> > > > > >>
> > > > > >>> As discussed at apachecon in Austin, i propose to switch from
> > svn to
> > > > git
> > > > > >>> for the ofbiz repository. The main reason being that all major
> > > > > >>> contributors are using git and contributions are cumbersome,
> > further,
> > > > > >>> git allows for better branching and merging.
> > > > > >>>
> > > > > >>> Regards,
> > > > > >>> Hans
> > > > > >>>
> > > > > >>
> > > > > >>
> > > >
> > > >
> > > >
> >
> >
> >
Re: move to git.
Posted by Pierre Smits <pi...@gmail.com>.
Thanks for what, Christian?
Ah.... It seems you're misunderstanding me as I might have been a bit to
brief. I have commit privileges in other projects. I don't have that
privilege in this project.
By the way, I have seen your recent git coalescence/aggregation regarding
various issues into one big-sized patch. Affecting multiple components.
This is, I surmise, the result of the way Git is utilised as a change
integration tool from various private development branches before
submitting patches/promoted. Which is a bit harder to achieve in SVN.
At the moment I am not certain whether to llike or dislike the end result
(the patch in question).
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Mon, Apr 20, 2015 at 10:26 PM, Christian Carlow <
christian.carlow@gmail.com> wrote:
> Thanks Pierre,
>
> I switched to git because committer privileges don't have to be granted
> before non-committers have access to development freedoms such as branch
> creations for conveniencies such as patch creation. Such a system seems
> to promote more open source collaboration.
>
> On Mon, 2015-04-20 at 21:49 +0200, Pierre Smits wrote:
> > I have currently multiple local development branches in our SVN and they
> > are SVN based and they are all of the same bases at
> > https://svn.apache.org/repos/asf/ofbiz.
> >
> > And yes, I have commit privileges.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *ORRTIZ.COM <http://www.orrtiz.com>*
> > Services & Solutions for Cloud-
> > Based Manufacturing, Professional
> > Services and Retail & Trade
> > http://www.orrtiz.com
> >
> > On Mon, Apr 20, 2015 at 8:37 PM, Christian Carlow <
> > christian.carlow@gmail.com> wrote:
> >
> > > SVN allows for a local branching? Believing git only allows this was
> > > the main reason for my recent switch. Are commit privileges not
> > > necessary for the creation of such an svn branch as is the case with
> > > git?
> > >
> > > On Mon, 2015-04-20 at 11:54 +0200, Pierre Smits wrote:
> > > > If we only want GIT for multiple local development branches, then we
> are
> > > > doing for the wrong reasons. SVN doesn't hinder you in doing that
> today.
> > > >
> > > > Best regards,
> > > >
> > > > Pierre Smits
> > > >
> > > > *ORRTIZ.COM <http://www.orrtiz.com>*
> > > > Services & Solutions for Cloud-
> > > > Based Manufacturing, Professional
> > > > Services and Retail & Trade
> > > > http://www.orrtiz.com
> > > >
> > > > On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux <
> > > > jacques.le.roux@les7arts.com> wrote:
> > > >
> > > > > Like Adrian and mostly for the same reasons, I don't believe we
> need
> > > Git.
> > > > >
> > > > > But there is one other major reason which has already been
> discussed in
> > > > > the other common ASF MLs. As Taher exulted, it's possible to
> create
> > > local
> > > > > branches. So people are able to do a lot of work alone without
> > > exchanging
> > > > > before committing or submitting. It will certainly not help to have
> > > this
> > > > > possibility. Remember our recent discussion on the lack or core
> commits
> > > > > reviews. With Git you end with commits bursts or big patches and
> it's
> > > then
> > > > > hard to review and too late to share ideas.
> > > > >
> > > > > So unlike Adrian, I'm even strongly against it. I will not
> hesitate to
> > > use
> > > > > a -1 if necessary!
> > > > >
> > > > > Jacques
> > > > >
> > > > >
> > > > > Le 20/04/2015 09:53, Adrian Crum a écrit :
> > > > >
> > > > >> I don't agree that "all major contributors are using git."
> > > > >>
> > > > >> Personally, I find Git to be an overly complicated solution to a
> > > simple
> > > > >> problem. It frequently does bizarre things that no one
> understands,
> > > and you
> > > > >> are left with things being mysteriously reverted for unknown
> reasons.
> > > > >>
> > > > >> This isn't a -1 vote though. I'm just making it clear that I will
> be
> > > > >> dragged kicking and screaming into using it.
> > > > >>
> > > > >> Adrian Crum
> > > > >> Sandglass Software
> > > > >> www.sandglass-software.com
> > > > >>
> > > > >> On 4/20/2015 5:38 AM, Hans Bakker wrote:
> > > > >>
> > > > >>> As discussed at apachecon in Austin, i propose to switch from
> svn to
> > > git
> > > > >>> for the ofbiz repository. The main reason being that all major
> > > > >>> contributors are using git and contributions are cumbersome,
> further,
> > > > >>> git allows for better branching and merging.
> > > > >>>
> > > > >>> Regards,
> > > > >>> Hans
> > > > >>>
> > > > >>
> > > > >>
> > >
> > >
> > >
>
>
>
Re: move to git.
Posted by Christian Carlow <ch...@gmail.com>.
Thanks Pierre,
I switched to git because committer privileges don't have to be granted
before non-committers have access to development freedoms such as branch
creations for conveniencies such as patch creation. Such a system seems
to promote more open source collaboration.
On Mon, 2015-04-20 at 21:49 +0200, Pierre Smits wrote:
> I have currently multiple local development branches in our SVN and they
> are SVN based and they are all of the same bases at
> https://svn.apache.org/repos/asf/ofbiz.
>
> And yes, I have commit privileges.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Mon, Apr 20, 2015 at 8:37 PM, Christian Carlow <
> christian.carlow@gmail.com> wrote:
>
> > SVN allows for a local branching? Believing git only allows this was
> > the main reason for my recent switch. Are commit privileges not
> > necessary for the creation of such an svn branch as is the case with
> > git?
> >
> > On Mon, 2015-04-20 at 11:54 +0200, Pierre Smits wrote:
> > > If we only want GIT for multiple local development branches, then we are
> > > doing for the wrong reasons. SVN doesn't hinder you in doing that today.
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > *ORRTIZ.COM <http://www.orrtiz.com>*
> > > Services & Solutions for Cloud-
> > > Based Manufacturing, Professional
> > > Services and Retail & Trade
> > > http://www.orrtiz.com
> > >
> > > On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux <
> > > jacques.le.roux@les7arts.com> wrote:
> > >
> > > > Like Adrian and mostly for the same reasons, I don't believe we need
> > Git.
> > > >
> > > > But there is one other major reason which has already been discussed in
> > > > the other common ASF MLs. As Taher exulted, it's possible to create
> > local
> > > > branches. So people are able to do a lot of work alone without
> > exchanging
> > > > before committing or submitting. It will certainly not help to have
> > this
> > > > possibility. Remember our recent discussion on the lack or core commits
> > > > reviews. With Git you end with commits bursts or big patches and it's
> > then
> > > > hard to review and too late to share ideas.
> > > >
> > > > So unlike Adrian, I'm even strongly against it. I will not hesitate to
> > use
> > > > a -1 if necessary!
> > > >
> > > > Jacques
> > > >
> > > >
> > > > Le 20/04/2015 09:53, Adrian Crum a écrit :
> > > >
> > > >> I don't agree that "all major contributors are using git."
> > > >>
> > > >> Personally, I find Git to be an overly complicated solution to a
> > simple
> > > >> problem. It frequently does bizarre things that no one understands,
> > and you
> > > >> are left with things being mysteriously reverted for unknown reasons.
> > > >>
> > > >> This isn't a -1 vote though. I'm just making it clear that I will be
> > > >> dragged kicking and screaming into using it.
> > > >>
> > > >> Adrian Crum
> > > >> Sandglass Software
> > > >> www.sandglass-software.com
> > > >>
> > > >> On 4/20/2015 5:38 AM, Hans Bakker wrote:
> > > >>
> > > >>> As discussed at apachecon in Austin, i propose to switch from svn to
> > git
> > > >>> for the ofbiz repository. The main reason being that all major
> > > >>> contributors are using git and contributions are cumbersome, further,
> > > >>> git allows for better branching and merging.
> > > >>>
> > > >>> Regards,
> > > >>> Hans
> > > >>>
> > > >>
> > > >>
> >
> >
> >
Re: move to git.
Posted by Pierre Smits <pi...@gmail.com>.
I have currently multiple local development branches in our SVN and they
are SVN based and they are all of the same bases at
https://svn.apache.org/repos/asf/ofbiz.
And yes, I have commit privileges.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Mon, Apr 20, 2015 at 8:37 PM, Christian Carlow <
christian.carlow@gmail.com> wrote:
> SVN allows for a local branching? Believing git only allows this was
> the main reason for my recent switch. Are commit privileges not
> necessary for the creation of such an svn branch as is the case with
> git?
>
> On Mon, 2015-04-20 at 11:54 +0200, Pierre Smits wrote:
> > If we only want GIT for multiple local development branches, then we are
> > doing for the wrong reasons. SVN doesn't hinder you in doing that today.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *ORRTIZ.COM <http://www.orrtiz.com>*
> > Services & Solutions for Cloud-
> > Based Manufacturing, Professional
> > Services and Retail & Trade
> > http://www.orrtiz.com
> >
> > On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux <
> > jacques.le.roux@les7arts.com> wrote:
> >
> > > Like Adrian and mostly for the same reasons, I don't believe we need
> Git.
> > >
> > > But there is one other major reason which has already been discussed in
> > > the other common ASF MLs. As Taher exulted, it's possible to create
> local
> > > branches. So people are able to do a lot of work alone without
> exchanging
> > > before committing or submitting. It will certainly not help to have
> this
> > > possibility. Remember our recent discussion on the lack or core commits
> > > reviews. With Git you end with commits bursts or big patches and it's
> then
> > > hard to review and too late to share ideas.
> > >
> > > So unlike Adrian, I'm even strongly against it. I will not hesitate to
> use
> > > a -1 if necessary!
> > >
> > > Jacques
> > >
> > >
> > > Le 20/04/2015 09:53, Adrian Crum a écrit :
> > >
> > >> I don't agree that "all major contributors are using git."
> > >>
> > >> Personally, I find Git to be an overly complicated solution to a
> simple
> > >> problem. It frequently does bizarre things that no one understands,
> and you
> > >> are left with things being mysteriously reverted for unknown reasons.
> > >>
> > >> This isn't a -1 vote though. I'm just making it clear that I will be
> > >> dragged kicking and screaming into using it.
> > >>
> > >> Adrian Crum
> > >> Sandglass Software
> > >> www.sandglass-software.com
> > >>
> > >> On 4/20/2015 5:38 AM, Hans Bakker wrote:
> > >>
> > >>> As discussed at apachecon in Austin, i propose to switch from svn to
> git
> > >>> for the ofbiz repository. The main reason being that all major
> > >>> contributors are using git and contributions are cumbersome, further,
> > >>> git allows for better branching and merging.
> > >>>
> > >>> Regards,
> > >>> Hans
> > >>>
> > >>
> > >>
>
>
>
Re: move to git.
Posted by Christian Carlow <ch...@gmail.com>.
SVN allows for a local branching? Believing git only allows this was
the main reason for my recent switch. Are commit privileges not
necessary for the creation of such an svn branch as is the case with
git?
On Mon, 2015-04-20 at 11:54 +0200, Pierre Smits wrote:
> If we only want GIT for multiple local development branches, then we are
> doing for the wrong reasons. SVN doesn't hinder you in doing that today.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
> > Like Adrian and mostly for the same reasons, I don't believe we need Git.
> >
> > But there is one other major reason which has already been discussed in
> > the other common ASF MLs. As Taher exulted, it's possible to create local
> > branches. So people are able to do a lot of work alone without exchanging
> > before committing or submitting. It will certainly not help to have this
> > possibility. Remember our recent discussion on the lack or core commits
> > reviews. With Git you end with commits bursts or big patches and it's then
> > hard to review and too late to share ideas.
> >
> > So unlike Adrian, I'm even strongly against it. I will not hesitate to use
> > a -1 if necessary!
> >
> > Jacques
> >
> >
> > Le 20/04/2015 09:53, Adrian Crum a écrit :
> >
> >> I don't agree that "all major contributors are using git."
> >>
> >> Personally, I find Git to be an overly complicated solution to a simple
> >> problem. It frequently does bizarre things that no one understands, and you
> >> are left with things being mysteriously reverted for unknown reasons.
> >>
> >> This isn't a -1 vote though. I'm just making it clear that I will be
> >> dragged kicking and screaming into using it.
> >>
> >> Adrian Crum
> >> Sandglass Software
> >> www.sandglass-software.com
> >>
> >> On 4/20/2015 5:38 AM, Hans Bakker wrote:
> >>
> >>> As discussed at apachecon in Austin, i propose to switch from svn to git
> >>> for the ofbiz repository. The main reason being that all major
> >>> contributors are using git and contributions are cumbersome, further,
> >>> git allows for better branching and merging.
> >>>
> >>> Regards,
> >>> Hans
> >>>
> >>
> >>
Re: move to git.
Posted by Pierre Smits <pi...@gmail.com>.
If we only want GIT for multiple local development branches, then we are
doing for the wrong reasons. SVN doesn't hinder you in doing that today.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> Like Adrian and mostly for the same reasons, I don't believe we need Git.
>
> But there is one other major reason which has already been discussed in
> the other common ASF MLs. As Taher exulted, it's possible to create local
> branches. So people are able to do a lot of work alone without exchanging
> before committing or submitting. It will certainly not help to have this
> possibility. Remember our recent discussion on the lack or core commits
> reviews. With Git you end with commits bursts or big patches and it's then
> hard to review and too late to share ideas.
>
> So unlike Adrian, I'm even strongly against it. I will not hesitate to use
> a -1 if necessary!
>
> Jacques
>
>
> Le 20/04/2015 09:53, Adrian Crum a écrit :
>
>> I don't agree that "all major contributors are using git."
>>
>> Personally, I find Git to be an overly complicated solution to a simple
>> problem. It frequently does bizarre things that no one understands, and you
>> are left with things being mysteriously reverted for unknown reasons.
>>
>> This isn't a -1 vote though. I'm just making it clear that I will be
>> dragged kicking and screaming into using it.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 4/20/2015 5:38 AM, Hans Bakker wrote:
>>
>>> As discussed at apachecon in Austin, i propose to switch from svn to git
>>> for the ofbiz repository. The main reason being that all major
>>> contributors are using git and contributions are cumbersome, further,
>>> git allows for better branching and merging.
>>>
>>> Regards,
>>> Hans
>>>
>>
>>
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 21/04/2015 02:26, Adam Heath a écrit :
>
> On 04/20/2015 04:12 AM, Jacques Le Roux wrote:
>> Like Adrian and mostly for the same reasons, I don't believe we need Git.
>>
>> But there is one other major reason which has already been discussed in the other common ASF MLs. As Taher exulted, it's possible to create local
>> branches. So people are able to do a lot of work alone without exchanging before committing or submitting. It will certainly not help to have this
>> possibility. Remember our recent discussion on the lack or core commits reviews. With Git you end with commits bursts or big patches and it's then
>> hard to review and too late to share ideas.
>>
>
> I take exception to this; I believe you are referring to my commit bursts, in times past. Aka, 10-15 commits get added to svn in under a minute.
>
> Git allows me to create a new feature, initially as a single large commit(or several large commits). Then, using the rebase feature, I pull out
> very small changes, that are easy to understand, and digest. I then might commit those as completely separate fixes/feature-additions, which then
> get reviewed. I then wait a bit, and rebase my big work on top of the new trunk.
>
> Eventually, I get the history to such a point that I feel that the series of commits are an easy to understand progression. At that point, I commit
> the entire set to svn.
>
> Note, that I run the entire set of test cases(as they exist at that point) against each and every single commit, before I send them off.
>
> Having each commit separate, allows for each change to be looked at in isolation. If they were all combined into one, then it would be much more
> difficult to review.
>
> If the number of commits at once is the problem, then I don't follow. Spreading each commit out over several hours still won't cause anything to
> get reviewed.
>
>
I can see your point and it's difficult to not agree. I though have still a feeling that with Git spirit less things will be shared and discussed
before being committed
Jacques
Re: move to git.
Posted by Adam Heath <do...@brainfood.com>.
On 04/20/2015 04:12 AM, Jacques Le Roux wrote:
> Like Adrian and mostly for the same reasons, I don't believe we need Git.
>
> But there is one other major reason which has already been discussed
> in the other common ASF MLs. As Taher exulted, it's possible to
> create local branches. So people are able to do a lot of work alone
> without exchanging before committing or submitting. It will certainly
> not help to have this possibility. Remember our recent discussion on
> the lack or core commits reviews. With Git you end with commits bursts
> or big patches and it's then hard to review and too late to share ideas.
>
I take exception to this; I believe you are referring to my commit
bursts, in times past. Aka, 10-15 commits get added to svn in under a
minute.
Git allows me to create a new feature, initially as a single large
commit(or several large commits). Then, using the rebase feature, I
pull out very small changes, that are easy to understand, and digest. I
then might commit those as completely separate fixes/feature-additions,
which then get reviewed. I then wait a bit, and rebase my big work on
top of the new trunk.
Eventually, I get the history to such a point that I feel that the
series of commits are an easy to understand progression. At that point,
I commit the entire set to svn.
Note, that I run the entire set of test cases(as they exist at that
point) against each and every single commit, before I send them off.
Having each commit separate, allows for each change to be looked at in
isolation. If they were all combined into one, then it would be much
more difficult to review.
If the number of commits at once is the problem, then I don't follow.
Spreading each commit out over several hours still won't cause anything
to get reviewed.
Re: move to git.
Posted by Pierre Smits <pi...@gmail.com>.
Some have argumented in this and other threads that SVN is dead and Git is
the new king, and that is why the change is warranted. Here are some
insights into numbers:
http://programmers.stackexchange.com/questions/136079/are-there-any-statistics-that-show-the-popularity-of-git-versus-svn
.
If you feel that SVN should address the GIT features, I suggest you join
user@subversion.a.o. or dev@subversion.a.o and collaborate there to get it
improved. Yes, SVN is an Apache project called Apache Subversion.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Tue, Apr 21, 2015 at 8:21 AM, Pierre Smits <pi...@gmail.com>
wrote:
> Quoting:
>
> We are also prepared to be assertive regarding this situation. If the
> project
> does not move to GIT then Brainfood is willing to participate in a
> consortium of
> organizations that will peer with each other to share updates to the master
> branch for their local OFBiz repository. Such an arrangement will,
> effectively,
> result in a distributed master repository image.
>
> Thanks Ean for the position of *Brainfood* in this position. It comes
> across as 'Do it our way, or else'. You are free to make such statements
> and when followed through there will be consequences. For all participating
> in this project. One I can see standing out clearly is: no more
> participation in/contribution from the employees of Brainfood and from the
> other companies in that consortium back into the project.
>
> If that is going to happen, I will say: 'I thank you for all the
> contributions you did to the project'. And I will check in my sentiments at
> the door. I do hope that if you do you also resign totally from this
> project.
>
>
> I rather have the community comes to its decision based on sound/valid
> arguments, not (veiled) threats.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler <ea...@brainfood.com> wrote:
>
>> ----- Original Message -----
>> > From: "Jacques Le Roux" <ja...@les7arts.com>
>> > Subject: Re: move to git.
>>
>> > Like Adrian and mostly for the same reasons, I don't believe we need
>> Git.
>> >
>> > But there is one other major reason which has already been discussed in
>> the
>> > other common ASF MLs. As Taher exulted, it's possible to create local
>> > branches. So people are able to do a lot of work alone without
>> exchanging before
>> > committing or submitting. It will certainly not help to have this
>> > possibility.
>>
>> I disagree. It is useful in many situations for OFBiz developers to
>> create a
>> local repository that is not globally shared. Some customers may even
>> require
>> such a situation for security or legal reasons.
>>
>> > Remember our recent discussion on the lack or core commits reviews.
>> > With Git you end with commits bursts or big patches and it's then
>> > hard to review and too late to share ideas.
>> >
>> > So unlike Adrian, I'm even strongly against it. I will not hesitate to
>> use a -1
>> > if necessary!
>>
>> We are also prepared to be assertive regarding this situation. If the
>> project
>> does not move to GIT then Brainfood is willing to participate in a
>> consortium of
>> organizations that will peer with each other to share updates to the
>> master
>> branch for their local OFBiz repository. Such an arrangement will,
>> effectively,
>> result in a distributed master repository image.
>>
>> If anyone else is interested in such an arrangement please feel free to
>> speak
>> up and we can begin the planning process.
>>
>
>
Re: move to git.
Posted by Ron Wheeler <rw...@artifact-software.com>.
I am not sure that this should come as a surprise or a real difference
in the current state.
It is possible for anyone to fork the project.
With git it could be easier to contribute back changes from this fork.
Of course, the code bases could diverge to a point where sharing updates
becomes too complex for both sides.
The real issue is whether there is sufficient dissatisfaction with the
current workflow and product direction for another community of
like-minded committers to build to a size capable of managing a "better"
fork.
Ron
On 21/04/2015 2:21 AM, Pierre Smits wrote:
> Quoting:
>
> We are also prepared to be assertive regarding this situation. If the
> project
> does not move to GIT then Brainfood is willing to participate in a
> consortium of
> organizations that will peer with each other to share updates to the master
> branch for their local OFBiz repository. Such an arrangement will,
> effectively,
> result in a distributed master repository image.
>
> Thanks Ean for the position of *Brainfood* in this position. It comes
> across as 'Do it our way, or else'. You are free to make such statements
> and when followed through there will be consequences. For all participating
> in this project. One I can see standing out clearly is: no more
> participation in/contribution from the employees of Brainfood and from the
> other companies in that consortium back into the project.
>
> If that is going to happen, I will say: 'I thank you for all the
> contributions you did to the project'. And I will check in my sentiments at
> the door. I do hope that if you do you also resign totally from this
> project.
>
>
> I rather have the community comes to its decision based on sound/valid
> arguments, not (veiled) threats.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler <ea...@brainfood.com> wrote:
>
>> ----- Original Message -----
>>> From: "Jacques Le Roux" <ja...@les7arts.com>
>>> Subject: Re: move to git.
>>> Like Adrian and mostly for the same reasons, I don't believe we need Git.
>>>
>>> But there is one other major reason which has already been discussed in
>> the
>>> other common ASF MLs. As Taher exulted, it's possible to create local
>>> branches. So people are able to do a lot of work alone without
>> exchanging before
>>> committing or submitting. It will certainly not help to have this
>>> possibility.
>> I disagree. It is useful in many situations for OFBiz developers to create
>> a
>> local repository that is not globally shared. Some customers may even
>> require
>> such a situation for security or legal reasons.
>>
>>> Remember our recent discussion on the lack or core commits reviews.
>>> With Git you end with commits bursts or big patches and it's then
>>> hard to review and too late to share ideas.
>>>
>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>> use a -1
>>> if necessary!
>> We are also prepared to be assertive regarding this situation. If the
>> project
>> does not move to GIT then Brainfood is willing to participate in a
>> consortium of
>> organizations that will peer with each other to share updates to the master
>> branch for their local OFBiz repository. Such an arrangement will,
>> effectively,
>> result in a distributed master repository image.
>>
>> If anyone else is interested in such an arrangement please feel free to
>> speak
>> up and we can begin the planning process.
>>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: move to git.
Posted by Ean Schuessler <ea...@brainfood.com>.
Comments inline.
> From: "Pierre Smits" <pi...@gmail.com>
> Subject: Re: move to git.
> Quoting:
> We are also prepared to be assertive regarding this situation.
<SNIP>
> Thanks Ean for the position of *Brainfood* in this position. It comes
> across as 'Do it our way, or else'. You are free to make such statements
> and when followed through there will be consequences. For all participating
> in this project. One I can see standing out clearly is: no more
> participation in/contribution from the employees of Brainfood and from the
> other companies in that consortium back into the project.
>
> If that is going to happen, I will say: 'I thank you for all the
> contributions you did to the project'. And I will check in my sentiments at
> the door. I do hope that if you do you also resign totally from this
> project.
I believe what I said was "we'll do it our way even if you continue to do it
your way". I'm not sure what the "or else" part of my message was. I would ask
you to explain that to me but I'm not sure its important to the discussion.
> I rather have the community comes to its decision based on sound/valid
> arguments, not (veiled) threats.
There were no threats in my message. A threat might read like "no participation
in/contribution from {insert group here} will be allowed if they try to do
something without my permission".
The Apache Way is to "be nice" and I think it would be nice if people could
pursue their own ideas about how to improve the project as long as they do not
coerce other members.
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 21/04/2015 17:53, Hans Bakker a écrit :
> It also shows that programmers like to change the world of the end-users, however forget to improve themselves the way they work....
Are you insinuating that I'm fossilised and against changes in order to improve the way I work? If so you are wrong!
Jacques
PS: I will be totally off for 3 days for personal reasons, so don't expect more posts from me before Sunday evening... Have fun...
Re: move to git.
Posted by Hans Bakker <h....@antwebsystems.com>.
Tough time ahead Jacques, these were exactly the 4 major subjects
informally discussed in Austin.
It also shows that programmers like to change the world of the
end-users, however forget to improve themselves the way they work....
Regards,
Hans
On 21/04/15 21:23, Jacques Le Roux wrote:
> Le 21/04/2015 16:00, Pierre Smits a écrit :
>> Quoting:
>>
>> At Apachecon, Apache's engineering and corporate leadership advised
>> me that
>> we
>> could move to using OFBiz to manage our issues instead of JIRA if we so
>> desire.
>>
>>
>> If we want to explore that path, I suggest we do that in a separate
>> thread.
>
> Please don't, so we would not only move to Git and/or Maven and/or
> Moqui but while doing so we would also compete with Jira? :-o
>
> Jacques
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 21/04/2015 16:00, Pierre Smits a écrit :
> Quoting:
>
> At Apachecon, Apache's engineering and corporate leadership advised me that
> we
> could move to using OFBiz to manage our issues instead of JIRA if we so
> desire.
>
>
> If we want to explore that path, I suggest we do that in a separate thread.
Please don't, so we would not only move to Git and/or Maven and/or Moqui but while doing so we would also compete with Jira? :-o
Jacques
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Tue, Apr 21, 2015 at 3:35 PM, Ean Schuessler <ea...@brainfood.com> wrote:
>
>> Comments inline.
>>
>>> From: "David E. Jones" <de...@me.com>
>>> Subject: Re: move to git.
>>> It may seem like chaos to have forks and changes spread all over the
>> place...
>>> but that isn't caused by the distributed source management approach,
>> it's just
>>> made visible and clear by the approach. Right now this exists on a large
>> scale
>>> for OFBiz, tons of forks and changes in them, but they are mostly not
>> visible
>>> or publicly available so there is no way for OFBiz committers to pull
>> changes
>>> from other repos... they basically have to be extracted into a patch
>> file and
>>> submitted through a Jira issue.
>>>
>>> In other words, the chaos exists and the distributed source management
>> enabled
>>> by git just makes it easier to track it all and tame it a bit.
>> Precisely so. With GIT the chaos stays at its source until other players
>> decide
>> it is worth pulling into their copies of the world. With SVN you get the
>> chaos
>> of every committer whether you want it or not. (Note: this includes
>> Brainfood's
>> chaos for anyone who wants to mischaracterize my comments as an attack)
>>
>>> On a side note, this is one of the reasons I have concerns about making
>> Moqui
>>> and related projects part of the ASF: the ASF community approach doesn't
>> fit
>>> very well with this distributed source management model (pull requests
>> are
>>> discouraged, all contributions should go through Jira issues... though I
>> don't
>>> know that this is a strict policy).
>> At Apachecon, Apache's engineering and corporate leadership advised me
>> that we
>> could move to using OFBiz to manage our issues instead of JIRA if we so
>> desire.
>>
Re: move to git.
Posted by Pierre Smits <pi...@gmail.com>.
Quoting:
At Apachecon, Apache's engineering and corporate leadership advised me that
we
could move to using OFBiz to manage our issues instead of JIRA if we so
desire.
If we want to explore that path, I suggest we do that in a separate thread.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Tue, Apr 21, 2015 at 3:35 PM, Ean Schuessler <ea...@brainfood.com> wrote:
> Comments inline.
>
> > From: "David E. Jones" <de...@me.com>
> > Subject: Re: move to git.
>
> > It may seem like chaos to have forks and changes spread all over the
> place...
> > but that isn't caused by the distributed source management approach,
> it's just
> > made visible and clear by the approach. Right now this exists on a large
> scale
> > for OFBiz, tons of forks and changes in them, but they are mostly not
> visible
> > or publicly available so there is no way for OFBiz committers to pull
> changes
> > from other repos... they basically have to be extracted into a patch
> file and
> > submitted through a Jira issue.
> >
> > In other words, the chaos exists and the distributed source management
> enabled
> > by git just makes it easier to track it all and tame it a bit.
>
> Precisely so. With GIT the chaos stays at its source until other players
> decide
> it is worth pulling into their copies of the world. With SVN you get the
> chaos
> of every committer whether you want it or not. (Note: this includes
> Brainfood's
> chaos for anyone who wants to mischaracterize my comments as an attack)
>
> > On a side note, this is one of the reasons I have concerns about making
> Moqui
> > and related projects part of the ASF: the ASF community approach doesn't
> fit
> > very well with this distributed source management model (pull requests
> are
> > discouraged, all contributions should go through Jira issues... though I
> don't
> > know that this is a strict policy).
>
> At Apachecon, Apache's engineering and corporate leadership advised me
> that we
> could move to using OFBiz to manage our issues instead of JIRA if we so
> desire.
>
Re: move to git.
Posted by Ean Schuessler <ea...@brainfood.com>.
Comments inline.
> From: "David E. Jones" <de...@me.com>
> Subject: Re: move to git.
> It may seem like chaos to have forks and changes spread all over the place...
> but that isn't caused by the distributed source management approach, it's just
> made visible and clear by the approach. Right now this exists on a large scale
> for OFBiz, tons of forks and changes in them, but they are mostly not visible
> or publicly available so there is no way for OFBiz committers to pull changes
> from other repos... they basically have to be extracted into a patch file and
> submitted through a Jira issue.
>
> In other words, the chaos exists and the distributed source management enabled
> by git just makes it easier to track it all and tame it a bit.
Precisely so. With GIT the chaos stays at its source until other players decide
it is worth pulling into their copies of the world. With SVN you get the chaos
of every committer whether you want it or not. (Note: this includes Brainfood's
chaos for anyone who wants to mischaracterize my comments as an attack)
> On a side note, this is one of the reasons I have concerns about making Moqui
> and related projects part of the ASF: the ASF community approach doesn't fit
> very well with this distributed source management model (pull requests are
> discouraged, all contributions should go through Jira issues... though I don't
> know that this is a strict policy).
At Apachecon, Apache's engineering and corporate leadership advised me that we
could move to using OFBiz to manage our issues instead of JIRA if we so desire.
Re: move to git.
Posted by Pierre Smits <pi...@gmail.com>.
Quoting:
they basically have to be extracted into a patch file and submitted through
a Jira issue
Which is a good approach with respect to improvements of the other kind
(improvements, not bug fixes) as they than can be assessed, regarding
applicability in light of the direction of the project and its works, by
all in the community. And not through some filtering mech of the various
subsets (of controlling/directing/dictating entities) of the community
before the contribution of the individual gets to the project.
It is the amalgamation/aggregation in the hierarchy described (by David)
that should be of more concern than the mere technical aspects of the tool
applied.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Tue, Apr 21, 2015 at 12:19 PM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
>
> Le 21/04/2015 12:02, David E. Jones a écrit :
>
>> On 20 Apr 2015, at 23:21, Pierre Smits <pi...@gmail.com> wrote:
>>>
>>> Quoting:
>>>
>>> We are also prepared to be assertive regarding this situation. If the
>>> project
>>> does not move to GIT then Brainfood is willing to participate in a
>>> consortium of
>>> organizations that will peer with each other to share updates to the
>>> master
>>> branch for their local OFBiz repository. Such an arrangement will,
>>> effectively,
>>> result in a distributed master repository image.
>>>
>>> Thanks Ean for the position of *Brainfood* in this position. It comes
>>> across as 'Do it our way, or else'. You are free to make such statements
>>> and when followed through there will be consequences. For all
>>> participating
>>> in this project. One I can see standing out clearly is: no more
>>> participation in/contribution from the employees of Brainfood and from
>>> the
>>> other companies in that consortium back into the project.
>>>
>> That's not at all what I get from Ean's comments. The magic of a
>> community-driven project is that people can collaborate on anything they
>> want, within the scope of the main project or as side projects. If the main
>> project doesn't provide something desired, then it is perfectly appropriate
>> for others to collaborate on that... better than doing it totally isolated.
>>
>> What Ean is talking about ties in with the general idea of distributed
>> source management and distributed development. The general idea is that
>> there may be many forks of the main source repo, potentially with various
>> branches for different improvements and changes. These are generally made
>> available publicly, like public GitHub forks of other public repositories
>> (though with git they can be hosted anywhere).
>>
>> Those who make changes can request that particular changes be pulled into
>> upstream repositories and then those who maintain the upstream repos (or
>> the main project repo if it bubbles up that high) can review them and pull
>> the changes if desired. Those who maintain upstream repos can also look
>> around for useful changes in forked repos and pull them in as desired.
>> Others who run their own forks can pull in changes from peer repositories
>> too.
>>
>> It may seem like chaos to have forks and changes spread all over the
>> place... but that isn't caused by the distributed source management
>> approach, it's just made visible and clear by the approach. Right now this
>> exists on a large scale for OFBiz, tons of forks and changes in them, but
>> they are mostly not visible or publicly available so there is no way for
>> OFBiz committers to pull changes from other repos... they basically have to
>> be extracted into a patch file and submitted through a Jira issue.
>>
>> In other words, the chaos exists and the distributed source management
>> enabled by git just makes it easier to track it all and tame it a bit.
>>
>> On a side note, this is one of the reasons I have concerns about making
>> Moqui and related projects part of the ASF: the ASF community approach
>> doesn't fit very well with this distributed source management model (pull
>> requests are discouraged, all contributions should go through Jira
>> issues... though I don't know that this is a strict policy).
>>
>> -David
>>
>
> Interesting David, it can be compared to the OFBiz-France association
> effort to leverage the Nereides addons and addons manager. I let aside the
> licenses issues, as long as it's no part of a released package there are no
> problems.
> What do you think OFBiz-France members?
>
> Jacques
>
>
>
>> If that is going to happen, I will say: 'I thank you for all the
>>> contributions you did to the project'. And I will check in my sentiments
>>> at
>>> the door. I do hope that if you do you also resign totally from this
>>> project.
>>>
>>>
>>> I rather have the community comes to its decision based on sound/valid
>>> arguments, not (veiled) threats.
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler <ea...@brainfood.com>
>>> wrote:
>>>
>>> ----- Original Message -----
>>>>
>>>>> From: "Jacques Le Roux" <ja...@les7arts.com>
>>>>> Subject: Re: move to git.
>>>>> Like Adrian and mostly for the same reasons, I don't believe we need
>>>>> Git.
>>>>>
>>>>> But there is one other major reason which has already been discussed in
>>>>>
>>>> the
>>>>
>>>>> other common ASF MLs. As Taher exulted, it's possible to create local
>>>>> branches. So people are able to do a lot of work alone without
>>>>>
>>>> exchanging before
>>>>
>>>>> committing or submitting. It will certainly not help to have this
>>>>> possibility.
>>>>>
>>>> I disagree. It is useful in many situations for OFBiz developers to
>>>> create
>>>> a
>>>> local repository that is not globally shared. Some customers may even
>>>> require
>>>> such a situation for security or legal reasons.
>>>>
>>>> Remember our recent discussion on the lack or core commits reviews.
>>>>> With Git you end with commits bursts or big patches and it's then
>>>>> hard to review and too late to share ideas.
>>>>>
>>>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>>>>>
>>>> use a -1
>>>>
>>>>> if necessary!
>>>>>
>>>> We are also prepared to be assertive regarding this situation. If the
>>>> project
>>>> does not move to GIT then Brainfood is willing to participate in a
>>>> consortium of
>>>> organizations that will peer with each other to share updates to the
>>>> master
>>>> branch for their local OFBiz repository. Such an arrangement will,
>>>> effectively,
>>>> result in a distributed master repository image.
>>>>
>>>> If anyone else is interested in such an arrangement please feel free to
>>>> speak
>>>> up and we can begin the planning process.
>>>>
>>>>
>>
>>
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
That's indeed what needs to be discussed and that why I asked OFBiz-France members opinions
Jacques
Le 21/04/2015 12:52, Pierre Smits a écrit :
> Sharing those improvements as patches attached to JIRA issues is a way
> better mechanism for exposure and review than through the distributed and
> competing search/find tools of today (Google et all) into all the
> distributed repositories or forks.
>
> Best regards,
>
> Pierre.
>
> Op dinsdag 21 april 2015 heeft Sharan Foga <sh...@gmail.com> het
> volgende geschreven:
>
>> Hi All
>>
>> I've been looking at some of what OFBiz France has done regarding addons
>> for OFBiz . I think there are a lot of useful things that have been
>> contributed by the community in general (not only OFBiz France) that are
>> either sitting in forks or addons or just in Jira that haven't really been
>> visible to the community.
>>
>> Making them visible gives the community more freedom and choice - whatever
>> tool is used.
>>
>> Thanks
>> Sharan
>>
>>
>>
>> On 21.4.2015 12:19, Jacques Le Roux wrote:
>>
>>> Le 21/04/2015 12:02, David E. Jones a écrit :
>>>
>>>> On 20 Apr 2015, at 23:21, Pierre Smits <pi...@gmail.com> wrote:
>>>>> Quoting:
>>>>>
>>>>> We are also prepared to be assertive regarding this situation. If the
>>>>> project
>>>>> does not move to GIT then Brainfood is willing to participate in a
>>>>> consortium of
>>>>> organizations that will peer with each other to share updates to the
>>>>> master
>>>>> branch for their local OFBiz repository. Such an arrangement will,
>>>>> effectively,
>>>>> result in a distributed master repository image.
>>>>>
>>>>> Thanks Ean for the position of *Brainfood* in this position. It comes
>>>>> across as 'Do it our way, or else'. You are free to make such statements
>>>>> and when followed through there will be consequences. For all
>>>>> participating
>>>>> in this project. One I can see standing out clearly is: no more
>>>>> participation in/contribution from the employees of Brainfood and from
>>>>> the
>>>>> other companies in that consortium back into the project.
>>>>>
>>>> That's not at all what I get from Ean's comments. The magic of a
>>>> community-driven project is that people can collaborate on anything they
>>>> want, within the scope of the main project or as side projects. If the main
>>>> project doesn't provide something desired, then it is perfectly appropriate
>>>> for others to collaborate on that... better than doing it totally isolated.
>>>>
>>>> What Ean is talking about ties in with the general idea of distributed
>>>> source management and distributed development. The general idea is that
>>>> there may be many forks of the main source repo, potentially with various
>>>> branches for different improvements and changes. These are generally made
>>>> available publicly, like public GitHub forks of other public repositories
>>>> (though with git they can be hosted anywhere).
>>>>
>>>> Those who make changes can request that particular changes be pulled
>>>> into upstream repositories and then those who maintain the upstream repos
>>>> (or the main project repo if it bubbles up that high) can review them and
>>>> pull the changes if desired. Those who maintain upstream repos can also
>>>> look around for useful changes in forked repos and pull them in as desired.
>>>> Others who run their own forks can pull in changes from peer repositories
>>>> too.
>>>>
>>>> It may seem like chaos to have forks and changes spread all over the
>>>> place... but that isn't caused by the distributed source management
>>>> approach, it's just made visible and clear by the approach. Right now this
>>>> exists on a large scale for OFBiz, tons of forks and changes in them, but
>>>> they are mostly not visible or publicly available so there is no way for
>>>> OFBiz committers to pull changes from other repos... they basically have to
>>>> be extracted into a patch file and submitted through a Jira issue.
>>>>
>>>> In other words, the chaos exists and the distributed source management
>>>> enabled by git just makes it easier to track it all and tame it a bit.
>>>>
>>>> On a side note, this is one of the reasons I have concerns about making
>>>> Moqui and related projects part of the ASF: the ASF community approach
>>>> doesn't fit very well with this distributed source management model (pull
>>>> requests are discouraged, all contributions should go through Jira
>>>> issues... though I don't know that this is a strict policy).
>>>>
>>>> -David
>>>>
>>> Interesting David, it can be compared to the OFBiz-France association
>>> effort to leverage the Nereides addons and addons manager. I let aside the
>>> licenses issues, as long as it's no part of a released package there are no
>>> problems.
>>> What do you think OFBiz-France members?
>>>
>>> Jacques
>>>
>>>
>>>> If that is going to happen, I will say: 'I thank you for all the
>>>>> contributions you did to the project'. And I will check in my
>>>>> sentiments at
>>>>> the door. I do hope that if you do you also resign totally from this
>>>>> project.
>>>>>
>>>>>
>>>>> I rather have the community comes to its decision based on sound/valid
>>>>> arguments, not (veiled) threats.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Pierre Smits
>>>>>
>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>> Services & Solutions for Cloud-
>>>>> Based Manufacturing, Professional
>>>>> Services and Retail & Trade
>>>>> http://www.orrtiz.com
>>>>>
>>>>> On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler <ea...@brainfood.com>
>>>>> wrote:
>>>>>
>>>>> ----- Original Message -----
>>>>>>> From: "Jacques Le Roux" <ja...@les7arts.com>
>>>>>>> Subject: Re: move to git.
>>>>>>> Like Adrian and mostly for the same reasons, I don't believe we need
>>>>>>> Git.
>>>>>>>
>>>>>>> But there is one other major reason which has already been discussed
>>>>>>> in
>>>>>>>
>>>>>> the
>>>>>>
>>>>>>> other common ASF MLs. As Taher exulted, it's possible to create local
>>>>>>> branches. So people are able to do a lot of work alone without
>>>>>>>
>>>>>> exchanging before
>>>>>>
>>>>>>> committing or submitting. It will certainly not help to have this
>>>>>>> possibility.
>>>>>>>
>>>>>> I disagree. It is useful in many situations for OFBiz developers to
>>>>>> create
>>>>>> a
>>>>>> local repository that is not globally shared. Some customers may even
>>>>>> require
>>>>>> such a situation for security or legal reasons.
>>>>>>
>>>>>> Remember our recent discussion on the lack or core commits reviews.
>>>>>>> With Git you end with commits bursts or big patches and it's then
>>>>>>> hard to review and too late to share ideas.
>>>>>>>
>>>>>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>>>>>>>
>>>>>> use a -1
>>>>>>
>>>>>>> if necessary!
>>>>>>>
>>>>>> We are also prepared to be assertive regarding this situation. If the
>>>>>> project
>>>>>> does not move to GIT then Brainfood is willing to participate in a
>>>>>> consortium of
>>>>>> organizations that will peer with each other to share updates to the
>>>>>> master
>>>>>> branch for their local OFBiz repository. Such an arrangement will,
>>>>>> effectively,
>>>>>> result in a distributed master repository image.
>>>>>>
>>>>>> If anyone else is interested in such an arrangement please feel free to
>>>>>> speak
>>>>>> up and we can begin the planning process.
>>>>>>
>>>>>>
>>>>
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
That's an important point indeed Pierre.
One thing we need to clarify is how "Git at the ASF" https://git-wip-us.apache.org/ allows to search between branches and forks, compared to svn and
patches in Jira
Of course we could add our own policy and tools
It doesn't mean I'm for using Git, it's only to allow comparing the alternatives. I have invested in using Jira and I'd really miss it...
Jacques
Le 21/04/2015 12:52, Pierre Smits a écrit :
> Sharing those improvements as patches attached to JIRA issues is a way
> better mechanism for exposure and review than through the distributed and
> competing search/find tools of today (Google et all) into all the
> distributed repositories or forks.
>
> Best regards,
>
> Pierre.
>
> Op dinsdag 21 april 2015 heeft Sharan Foga <sh...@gmail.com> het
> volgende geschreven:
>
>> Hi All
>>
>> I've been looking at some of what OFBiz France has done regarding addons
>> for OFBiz . I think there are a lot of useful things that have been
>> contributed by the community in general (not only OFBiz France) that are
>> either sitting in forks or addons or just in Jira that haven't really been
>> visible to the community.
>>
>> Making them visible gives the community more freedom and choice - whatever
>> tool is used.
>>
>> Thanks
>> Sharan
>>
>>
>>
>> On 21.4.2015 12:19, Jacques Le Roux wrote:
>>
>>> Le 21/04/2015 12:02, David E. Jones a écrit :
>>>
>>>> On 20 Apr 2015, at 23:21, Pierre Smits <pi...@gmail.com> wrote:
>>>>> Quoting:
>>>>>
>>>>> We are also prepared to be assertive regarding this situation. If the
>>>>> project
>>>>> does not move to GIT then Brainfood is willing to participate in a
>>>>> consortium of
>>>>> organizations that will peer with each other to share updates to the
>>>>> master
>>>>> branch for their local OFBiz repository. Such an arrangement will,
>>>>> effectively,
>>>>> result in a distributed master repository image.
>>>>>
>>>>> Thanks Ean for the position of *Brainfood* in this position. It comes
>>>>> across as 'Do it our way, or else'. You are free to make such statements
>>>>> and when followed through there will be consequences. For all
>>>>> participating
>>>>> in this project. One I can see standing out clearly is: no more
>>>>> participation in/contribution from the employees of Brainfood and from
>>>>> the
>>>>> other companies in that consortium back into the project.
>>>>>
>>>> That's not at all what I get from Ean's comments. The magic of a
>>>> community-driven project is that people can collaborate on anything they
>>>> want, within the scope of the main project or as side projects. If the main
>>>> project doesn't provide something desired, then it is perfectly appropriate
>>>> for others to collaborate on that... better than doing it totally isolated.
>>>>
>>>> What Ean is talking about ties in with the general idea of distributed
>>>> source management and distributed development. The general idea is that
>>>> there may be many forks of the main source repo, potentially with various
>>>> branches for different improvements and changes. These are generally made
>>>> available publicly, like public GitHub forks of other public repositories
>>>> (though with git they can be hosted anywhere).
>>>>
>>>> Those who make changes can request that particular changes be pulled
>>>> into upstream repositories and then those who maintain the upstream repos
>>>> (or the main project repo if it bubbles up that high) can review them and
>>>> pull the changes if desired. Those who maintain upstream repos can also
>>>> look around for useful changes in forked repos and pull them in as desired.
>>>> Others who run their own forks can pull in changes from peer repositories
>>>> too.
>>>>
>>>> It may seem like chaos to have forks and changes spread all over the
>>>> place... but that isn't caused by the distributed source management
>>>> approach, it's just made visible and clear by the approach. Right now this
>>>> exists on a large scale for OFBiz, tons of forks and changes in them, but
>>>> they are mostly not visible or publicly available so there is no way for
>>>> OFBiz committers to pull changes from other repos... they basically have to
>>>> be extracted into a patch file and submitted through a Jira issue.
>>>>
>>>> In other words, the chaos exists and the distributed source management
>>>> enabled by git just makes it easier to track it all and tame it a bit.
>>>>
>>>> On a side note, this is one of the reasons I have concerns about making
>>>> Moqui and related projects part of the ASF: the ASF community approach
>>>> doesn't fit very well with this distributed source management model (pull
>>>> requests are discouraged, all contributions should go through Jira
>>>> issues... though I don't know that this is a strict policy).
>>>>
>>>> -David
>>>>
>>> Interesting David, it can be compared to the OFBiz-France association
>>> effort to leverage the Nereides addons and addons manager. I let aside the
>>> licenses issues, as long as it's no part of a released package there are no
>>> problems.
>>> What do you think OFBiz-France members?
>>>
>>> Jacques
>>>
>>>
>>>> If that is going to happen, I will say: 'I thank you for all the
>>>>> contributions you did to the project'. And I will check in my
>>>>> sentiments at
>>>>> the door. I do hope that if you do you also resign totally from this
>>>>> project.
>>>>>
>>>>>
>>>>> I rather have the community comes to its decision based on sound/valid
>>>>> arguments, not (veiled) threats.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Pierre Smits
>>>>>
>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>> Services & Solutions for Cloud-
>>>>> Based Manufacturing, Professional
>>>>> Services and Retail & Trade
>>>>> http://www.orrtiz.com
>>>>>
>>>>> On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler <ea...@brainfood.com>
>>>>> wrote:
>>>>>
>>>>> ----- Original Message -----
>>>>>>> From: "Jacques Le Roux" <ja...@les7arts.com>
>>>>>>> Subject: Re: move to git.
>>>>>>> Like Adrian and mostly for the same reasons, I don't believe we need
>>>>>>> Git.
>>>>>>>
>>>>>>> But there is one other major reason which has already been discussed
>>>>>>> in
>>>>>>>
>>>>>> the
>>>>>>
>>>>>>> other common ASF MLs. As Taher exulted, it's possible to create local
>>>>>>> branches. So people are able to do a lot of work alone without
>>>>>>>
>>>>>> exchanging before
>>>>>>
>>>>>>> committing or submitting. It will certainly not help to have this
>>>>>>> possibility.
>>>>>>>
>>>>>> I disagree. It is useful in many situations for OFBiz developers to
>>>>>> create
>>>>>> a
>>>>>> local repository that is not globally shared. Some customers may even
>>>>>> require
>>>>>> such a situation for security or legal reasons.
>>>>>>
>>>>>> Remember our recent discussion on the lack or core commits reviews.
>>>>>>> With Git you end with commits bursts or big patches and it's then
>>>>>>> hard to review and too late to share ideas.
>>>>>>>
>>>>>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>>>>>>>
>>>>>> use a -1
>>>>>>
>>>>>>> if necessary!
>>>>>>>
>>>>>> We are also prepared to be assertive regarding this situation. If the
>>>>>> project
>>>>>> does not move to GIT then Brainfood is willing to participate in a
>>>>>> consortium of
>>>>>> organizations that will peer with each other to share updates to the
>>>>>> master
>>>>>> branch for their local OFBiz repository. Such an arrangement will,
>>>>>> effectively,
>>>>>> result in a distributed master repository image.
>>>>>>
>>>>>> If anyone else is interested in such an arrangement please feel free to
>>>>>> speak
>>>>>> up and we can begin the planning process.
>>>>>>
>>>>>>
>>>>
Re: move to git.
Posted by Pierre Smits <pi...@gmail.com>.
Sharing those improvements as patches attached to JIRA issues is a way
better mechanism for exposure and review than through the distributed and
competing search/find tools of today (Google et all) into all the
distributed repositories or forks.
Best regards,
Pierre.
Op dinsdag 21 april 2015 heeft Sharan Foga <sh...@gmail.com> het
volgende geschreven:
> Hi All
>
> I've been looking at some of what OFBiz France has done regarding addons
> for OFBiz . I think there are a lot of useful things that have been
> contributed by the community in general (not only OFBiz France) that are
> either sitting in forks or addons or just in Jira that haven't really been
> visible to the community.
>
> Making them visible gives the community more freedom and choice - whatever
> tool is used.
>
> Thanks
> Sharan
>
>
>
> On 21.4.2015 12:19, Jacques Le Roux wrote:
>
>>
>> Le 21/04/2015 12:02, David E. Jones a écrit :
>>
>>> On 20 Apr 2015, at 23:21, Pierre Smits <pi...@gmail.com> wrote:
>>>>
>>>> Quoting:
>>>>
>>>> We are also prepared to be assertive regarding this situation. If the
>>>> project
>>>> does not move to GIT then Brainfood is willing to participate in a
>>>> consortium of
>>>> organizations that will peer with each other to share updates to the
>>>> master
>>>> branch for their local OFBiz repository. Such an arrangement will,
>>>> effectively,
>>>> result in a distributed master repository image.
>>>>
>>>> Thanks Ean for the position of *Brainfood* in this position. It comes
>>>> across as 'Do it our way, or else'. You are free to make such statements
>>>> and when followed through there will be consequences. For all
>>>> participating
>>>> in this project. One I can see standing out clearly is: no more
>>>> participation in/contribution from the employees of Brainfood and from
>>>> the
>>>> other companies in that consortium back into the project.
>>>>
>>> That's not at all what I get from Ean's comments. The magic of a
>>> community-driven project is that people can collaborate on anything they
>>> want, within the scope of the main project or as side projects. If the main
>>> project doesn't provide something desired, then it is perfectly appropriate
>>> for others to collaborate on that... better than doing it totally isolated.
>>>
>>> What Ean is talking about ties in with the general idea of distributed
>>> source management and distributed development. The general idea is that
>>> there may be many forks of the main source repo, potentially with various
>>> branches for different improvements and changes. These are generally made
>>> available publicly, like public GitHub forks of other public repositories
>>> (though with git they can be hosted anywhere).
>>>
>>> Those who make changes can request that particular changes be pulled
>>> into upstream repositories and then those who maintain the upstream repos
>>> (or the main project repo if it bubbles up that high) can review them and
>>> pull the changes if desired. Those who maintain upstream repos can also
>>> look around for useful changes in forked repos and pull them in as desired.
>>> Others who run their own forks can pull in changes from peer repositories
>>> too.
>>>
>>> It may seem like chaos to have forks and changes spread all over the
>>> place... but that isn't caused by the distributed source management
>>> approach, it's just made visible and clear by the approach. Right now this
>>> exists on a large scale for OFBiz, tons of forks and changes in them, but
>>> they are mostly not visible or publicly available so there is no way for
>>> OFBiz committers to pull changes from other repos... they basically have to
>>> be extracted into a patch file and submitted through a Jira issue.
>>>
>>> In other words, the chaos exists and the distributed source management
>>> enabled by git just makes it easier to track it all and tame it a bit.
>>>
>>> On a side note, this is one of the reasons I have concerns about making
>>> Moqui and related projects part of the ASF: the ASF community approach
>>> doesn't fit very well with this distributed source management model (pull
>>> requests are discouraged, all contributions should go through Jira
>>> issues... though I don't know that this is a strict policy).
>>>
>>> -David
>>>
>>
>> Interesting David, it can be compared to the OFBiz-France association
>> effort to leverage the Nereides addons and addons manager. I let aside the
>> licenses issues, as long as it's no part of a released package there are no
>> problems.
>> What do you think OFBiz-France members?
>>
>> Jacques
>>
>>
>>> If that is going to happen, I will say: 'I thank you for all the
>>>> contributions you did to the project'. And I will check in my
>>>> sentiments at
>>>> the door. I do hope that if you do you also resign totally from this
>>>> project.
>>>>
>>>>
>>>> I rather have the community comes to its decision based on sound/valid
>>>> arguments, not (veiled) threats.
>>>>
>>>> Best regards,
>>>>
>>>> Pierre Smits
>>>>
>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>> Services & Solutions for Cloud-
>>>> Based Manufacturing, Professional
>>>> Services and Retail & Trade
>>>> http://www.orrtiz.com
>>>>
>>>> On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler <ea...@brainfood.com>
>>>> wrote:
>>>>
>>>> ----- Original Message -----
>>>>>
>>>>>> From: "Jacques Le Roux" <ja...@les7arts.com>
>>>>>> Subject: Re: move to git.
>>>>>> Like Adrian and mostly for the same reasons, I don't believe we need
>>>>>> Git.
>>>>>>
>>>>>> But there is one other major reason which has already been discussed
>>>>>> in
>>>>>>
>>>>> the
>>>>>
>>>>>> other common ASF MLs. As Taher exulted, it's possible to create local
>>>>>> branches. So people are able to do a lot of work alone without
>>>>>>
>>>>> exchanging before
>>>>>
>>>>>> committing or submitting. It will certainly not help to have this
>>>>>> possibility.
>>>>>>
>>>>> I disagree. It is useful in many situations for OFBiz developers to
>>>>> create
>>>>> a
>>>>> local repository that is not globally shared. Some customers may even
>>>>> require
>>>>> such a situation for security or legal reasons.
>>>>>
>>>>> Remember our recent discussion on the lack or core commits reviews.
>>>>>> With Git you end with commits bursts or big patches and it's then
>>>>>> hard to review and too late to share ideas.
>>>>>>
>>>>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>>>>>>
>>>>> use a -1
>>>>>
>>>>>> if necessary!
>>>>>>
>>>>> We are also prepared to be assertive regarding this situation. If the
>>>>> project
>>>>> does not move to GIT then Brainfood is willing to participate in a
>>>>> consortium of
>>>>> organizations that will peer with each other to share updates to the
>>>>> master
>>>>> branch for their local OFBiz repository. Such an arrangement will,
>>>>> effectively,
>>>>> result in a distributed master repository image.
>>>>>
>>>>> If anyone else is interested in such an arrangement please feel free to
>>>>> speak
>>>>> up and we can begin the planning process.
>>>>>
>>>>>
>>>
>>>
>
--
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
Re: move to git.
Posted by Sharan Foga <sh...@gmail.com>.
Hi All
I've been looking at some of what OFBiz France has done regarding addons
for OFBiz . I think there are a lot of useful things that have been
contributed by the community in general (not only OFBiz France) that are
either sitting in forks or addons or just in Jira that haven't really
been visible to the community.
Making them visible gives the community more freedom and choice -
whatever tool is used.
Thanks
Sharan
On 21.4.2015 12:19, Jacques Le Roux wrote:
>
> Le 21/04/2015 12:02, David E. Jones a écrit :
>>> On 20 Apr 2015, at 23:21, Pierre Smits <pi...@gmail.com> wrote:
>>>
>>> Quoting:
>>>
>>> We are also prepared to be assertive regarding this situation. If the
>>> project
>>> does not move to GIT then Brainfood is willing to participate in a
>>> consortium of
>>> organizations that will peer with each other to share updates to the
>>> master
>>> branch for their local OFBiz repository. Such an arrangement will,
>>> effectively,
>>> result in a distributed master repository image.
>>>
>>> Thanks Ean for the position of *Brainfood* in this position. It comes
>>> across as 'Do it our way, or else'. You are free to make such
>>> statements
>>> and when followed through there will be consequences. For all
>>> participating
>>> in this project. One I can see standing out clearly is: no more
>>> participation in/contribution from the employees of Brainfood and
>>> from the
>>> other companies in that consortium back into the project.
>> That's not at all what I get from Ean's comments. The magic of a
>> community-driven project is that people can collaborate on anything
>> they want, within the scope of the main project or as side projects.
>> If the main project doesn't provide something desired, then it is
>> perfectly appropriate for others to collaborate on that... better
>> than doing it totally isolated.
>>
>> What Ean is talking about ties in with the general idea of
>> distributed source management and distributed development. The
>> general idea is that there may be many forks of the main source repo,
>> potentially with various branches for different improvements and
>> changes. These are generally made available publicly, like public
>> GitHub forks of other public repositories (though with git they can
>> be hosted anywhere).
>>
>> Those who make changes can request that particular changes be pulled
>> into upstream repositories and then those who maintain the upstream
>> repos (or the main project repo if it bubbles up that high) can
>> review them and pull the changes if desired. Those who maintain
>> upstream repos can also look around for useful changes in forked
>> repos and pull them in as desired. Others who run their own forks can
>> pull in changes from peer repositories too.
>>
>> It may seem like chaos to have forks and changes spread all over the
>> place... but that isn't caused by the distributed source management
>> approach, it's just made visible and clear by the approach. Right now
>> this exists on a large scale for OFBiz, tons of forks and changes in
>> them, but they are mostly not visible or publicly available so there
>> is no way for OFBiz committers to pull changes from other repos...
>> they basically have to be extracted into a patch file and submitted
>> through a Jira issue.
>>
>> In other words, the chaos exists and the distributed source
>> management enabled by git just makes it easier to track it all and
>> tame it a bit.
>>
>> On a side note, this is one of the reasons I have concerns about
>> making Moqui and related projects part of the ASF: the ASF community
>> approach doesn't fit very well with this distributed source
>> management model (pull requests are discouraged, all contributions
>> should go through Jira issues... though I don't know that this is a
>> strict policy).
>>
>> -David
>
> Interesting David, it can be compared to the OFBiz-France association
> effort to leverage the Nereides addons and addons manager. I let aside
> the licenses issues, as long as it's no part of a released package
> there are no problems.
> What do you think OFBiz-France members?
>
> Jacques
>
>>
>>> If that is going to happen, I will say: 'I thank you for all the
>>> contributions you did to the project'. And I will check in my
>>> sentiments at
>>> the door. I do hope that if you do you also resign totally from this
>>> project.
>>>
>>>
>>> I rather have the community comes to its decision based on sound/valid
>>> arguments, not (veiled) threats.
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler <ea...@brainfood.com>
>>> wrote:
>>>
>>>> ----- Original Message -----
>>>>> From: "Jacques Le Roux" <ja...@les7arts.com>
>>>>> Subject: Re: move to git.
>>>>> Like Adrian and mostly for the same reasons, I don't believe we
>>>>> need Git.
>>>>>
>>>>> But there is one other major reason which has already been
>>>>> discussed in
>>>> the
>>>>> other common ASF MLs. As Taher exulted, it's possible to create
>>>>> local
>>>>> branches. So people are able to do a lot of work alone without
>>>> exchanging before
>>>>> committing or submitting. It will certainly not help to have this
>>>>> possibility.
>>>> I disagree. It is useful in many situations for OFBiz developers to
>>>> create
>>>> a
>>>> local repository that is not globally shared. Some customers may even
>>>> require
>>>> such a situation for security or legal reasons.
>>>>
>>>>> Remember our recent discussion on the lack or core commits reviews.
>>>>> With Git you end with commits bursts or big patches and it's then
>>>>> hard to review and too late to share ideas.
>>>>>
>>>>> So unlike Adrian, I'm even strongly against it. I will not
>>>>> hesitate to
>>>> use a -1
>>>>> if necessary!
>>>> We are also prepared to be assertive regarding this situation. If the
>>>> project
>>>> does not move to GIT then Brainfood is willing to participate in a
>>>> consortium of
>>>> organizations that will peer with each other to share updates to
>>>> the master
>>>> branch for their local OFBiz repository. Such an arrangement will,
>>>> effectively,
>>>> result in a distributed master repository image.
>>>>
>>>> If anyone else is interested in such an arrangement please feel
>>>> free to
>>>> speak
>>>> up and we can begin the planning process.
>>>>
>>
>>
Re: move to git.
Posted by Ean Schuessler <ea...@brainfood.com>.
> From: "Pierre Smits" <pi...@gmail.com>
> Subject: Re: move to git.
> By committers referencing the contributors to the JIRA issue in the commit
> report.
But that is not reflected in your referenced visualization:
https://fisheye6.atlassian.com/users/ofbiz
I think it would be easier if you simply concede that the current process
does not let "svn blame" report the actual authors for patch lines.
Here is a simple enough question, "which non-committer has submitted the
most code to OFBiz and what was the distribution of their changes amongst
the various OFBiz components?"
Re: move to git.
Posted by Pierre Smits <pi...@gmail.com>.
It occasionally happens that committers don't reference the contributors.
But that is seldom.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Wed, Apr 22, 2015 at 8:05 PM, Adam Heath <do...@brainfood.com> wrote:
>
> On 04/22/2015 01:00 PM, Pierre Smits wrote:
>
>> By committers referencing the contributors to the JIRA issue in the commit
>> report.
>>
>
> But that's not reflected in the links you provided, or users aren't
> getting mentioned. With the git workflow, whoever created the commit will
> *definately* be recorded, it doesn't require some free-form text message,
> that may or may not be parsed correctly.
>
>
Re: move to git.
Posted by "David E. Jones" <de...@me.com>.
> On 22 Apr 2015, at 16:14, Pierre Smits <pi...@gmail.com> wrote:
>
> Indeed, let's not amalgamate everything and keep the discussion clean. The
> https://fisheye6.atlassian.com/graph/ofbiz does show information about the
> jira issue (including the contributor, if done correctly). Just click on
> the blue i icon to the right of the comment excerpt. You'll see a modal
> window appearing with more info. Take as an example the commit done on
> April 18th starting with comment: 'A patch from Pierre Smits...'
>
> Thank you for sharing insights in how Git could work for this project. I
> appreciate it.
>
> Can you provide links to examples of an Apache project using Git that shows
> a contribution from a non-privileged contributor as you describe? It would
> surely help understanding the described visibility and help this community
> to make a sound decision when all has been said.
Not an ASF project, but here is an example of what that can look like (and demonstrating the shameful lack of community in Moqui Framework). In this case I am the only person with push/write permission to this git repository, so all others came through pull requests after they committed to their own fork repositories:
https://github.com/moqui/moqui/graphs/contributors
> Quoting:
>
> which non-committer has submitted the most code to OFBiz and what was the
> distribution of their changes amongst the various OFBiz components?
>
>
> I would love to see that too. Maybe our PMC chair can clarify and comment
> on that?
The PMC chair doesn't have access to any magic tools that are unavailable to the rest of us... this is an unknown (even if we can get approximate data from Jira and SVN).
-David
Re: move to git.
Posted by Adam Heath <do...@brainfood.com>.
https://github.com/ansible/ansible/graphs/contributors
mpdehaan used to be *the* ansible guy. It was his original creation.
He has since moved on, but 1000 contributors that have actual code
inside the primary repository.
Also look at
https://github.com/ansible/ansible/graphs/contributors?from=2012-11-23&to=2013-05-03&type=c,
which shows how you can have a draggable window; but having a nice gui
is not what this sub-discussion is about.
On 04/22/2015 06:14 PM, Pierre Smits wrote:
> Indeed, let's not amalgamate everything and keep the discussion clean. The
> https://fisheye6.atlassian.com/graph/ofbiz does show information about the
> jira issue (including the contributor, if done correctly). Just click on
> the blue i icon to the right of the comment excerpt. You'll see a modal
> window appearing with more info. Take as an example the commit done on
> April 18th starting with comment: 'A patch from Pierre Smits...'
>
> Thank you for sharing insights in how Git could work for this project. I
> appreciate it.
>
> Can you provide links to examples of an Apache project using Git that shows
> a contribution from a non-privileged contributor as you describe? It would
> surely help understanding the described visibility and help this community
> to make a sound decision when all has been said.
>
> Quoting:
>
> which non-committer has submitted the most code to OFBiz and what was the
> distribution of their changes amongst the various OFBiz components?
>
>
> I would love to see that too. Maybe our PMC chair can clarify and comment
> on that?
>
> Please remember: if anyone feels that this discussion has reached a
> saturation point (all viewpoints and concerns presented) and a sense of
> consensus needs to be established, just call a vote. The outcome will
> dictate the direction. To me this seems a procedural issue, not a code
> change.
>
> Best regards,
>
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
Re: move to git.
Posted by Pierre Smits <pi...@gmail.com>.
Indeed, let's not amalgamate everything and keep the discussion clean. The
https://fisheye6.atlassian.com/graph/ofbiz does show information about the
jira issue (including the contributor, if done correctly). Just click on
the blue i icon to the right of the comment excerpt. You'll see a modal
window appearing with more info. Take as an example the commit done on
April 18th starting with comment: 'A patch from Pierre Smits...'
Thank you for sharing insights in how Git could work for this project. I
appreciate it.
Can you provide links to examples of an Apache project using Git that shows
a contribution from a non-privileged contributor as you describe? It would
surely help understanding the described visibility and help this community
to make a sound decision when all has been said.
Quoting:
which non-committer has submitted the most code to OFBiz and what was the
distribution of their changes amongst the various OFBiz components?
I would love to see that too. Maybe our PMC chair can clarify and comment
on that?
Please remember: if anyone feels that this discussion has reached a
saturation point (all viewpoints and concerns presented) and a sense of
consensus needs to be established, just call a vote. The outcome will
dictate the direction. To me this seems a procedural issue, not a code
change.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 23/04/2015 01:54, David E. Jones a écrit :
>> On 22 Apr 2015, at 16:49, Adam Heath <do...@brainfood.com> wrote:
>>
>>
>> On 04/22/2015 06:13 PM, Jacopo Cappellato wrote:
>>> On Apr 22, 2015, at 11:41 PM, Adam Heath <do...@brainfood.com> wrote:
>>>
>>>> When this happened, we had to relicense the entire project from GPL to Apache 2.0.
>>> Grrrrr.... It was not GPL! :-)
>> It was something tho; I may be wrong on that, I didn't actually look it up. I do recall that switching was quite the ordeal.
> It was MIT, but that wasn't the real issue with all the CLAs... the ASF requires them but they are not generally required for other users of the Apache 2 license.
I was expecting you to say it, thanks David!
Jacques
>
> This was a pain... took months of effort. Even under the ASF we don't know who all code has come from, there is no way to get a list from SVN or any other tool... not even from Jira (though that's closer, but we only have associations between those who opened issues or attached a patch or those sorts of activities, doesn't always match exactly which patch gets committed, etc... AND not all commits get linked back to the Jira issues... oh and mentioning a name in a commit, pretty useless from a reporting perspective... parsing difficulties, data cleanliness/consistency issues... nightmare).
>
> -David
>
>
>
Re: move to git.
Posted by "David E. Jones" <de...@me.com>.
> On 22 Apr 2015, at 16:49, Adam Heath <do...@brainfood.com> wrote:
>
>
> On 04/22/2015 06:13 PM, Jacopo Cappellato wrote:
>> On Apr 22, 2015, at 11:41 PM, Adam Heath <do...@brainfood.com> wrote:
>>
>>> When this happened, we had to relicense the entire project from GPL to Apache 2.0.
>> Grrrrr.... It was not GPL! :-)
>
> It was something tho; I may be wrong on that, I didn't actually look it up. I do recall that switching was quite the ordeal.
It was MIT, but that wasn't the real issue with all the CLAs... the ASF requires them but they are not generally required for other users of the Apache 2 license.
This was a pain... took months of effort. Even under the ASF we don't know who all code has come from, there is no way to get a list from SVN or any other tool... not even from Jira (though that's closer, but we only have associations between those who opened issues or attached a patch or those sorts of activities, doesn't always match exactly which patch gets committed, etc... AND not all commits get linked back to the Jira issues... oh and mentioning a name in a commit, pretty useless from a reporting perspective... parsing difficulties, data cleanliness/consistency issues... nightmare).
-David
Re: move to git.
Posted by Adam Heath <do...@brainfood.com>.
On 04/22/2015 06:13 PM, Jacopo Cappellato wrote:
> On Apr 22, 2015, at 11:41 PM, Adam Heath <do...@brainfood.com> wrote:
>
>> When this happened, we had to relicense the entire project from GPL to Apache 2.0.
> Grrrrr.... It was not GPL! :-)
It was something tho; I may be wrong on that, I didn't actually look it
up. I do recall that switching was quite the ordeal.
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Thanks Jacopo, from this point I was ready to jump, it was MIT!
I guess someone else already told me, just that I'm have not read it in my 1095 initial emails backlog yet :/
Jacques
Le 23/04/2015 01:13, Jacopo Cappellato a écrit :
> On Apr 22, 2015, at 11:41 PM, Adam Heath <do...@brainfood.com> wrote:
>
>> When this happened, we had to relicense the entire project from GPL to Apache 2.0.
> Grrrrr.... It was not GPL! :-)
>
> Jacopo
>
Re: move to git.
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
On Apr 22, 2015, at 11:41 PM, Adam Heath <do...@brainfood.com> wrote:
> When this happened, we had to relicense the entire project from GPL to Apache 2.0.
Grrrrr.... It was not GPL! :-)
Jacopo
Re: move to git.
Posted by Adam Heath <do...@brainfood.com>.
The links you provide only show developers who have write access to
svn. Git(not just github, let's not conflate anything) keeps track of
more than that. If there was someone who had forked a repo, comitted
something on their local desktop, then pushed to a public server, and
then someone on the offiicially sanctioned ofbiz git repo pulled from
this other source, then the original committor will now show as a
contributor.
And, besides, that isn't the point. The links you provided do *not*
show anyone from jira. Full stop. They *only* show people who have
write access to svn. Full stop.
In the past, ofbiz made a decision to move to apache.org. When this
happened, we had to relicense the entire project from GPL to Apache
2.0. This required finding all current and past SVN contributors, and
asking their permission. Then, all commit messages were scrubbed, and
if some user was mentioned in passing, they had to then be tracked down
and ask their permission as well.
The links you provide still do not show these additional patch
suppliers, and would not have helped.
If someone creates an issue in jira, then someone *else* uploads a file
and attaches a patch, it is this someone else that is the owner of the
code. Show me how you can track that down.
On 04/22/2015 03:49 PM, Pierre Smits wrote:
> Github shows the committers as contributors. The links I provided just
> shows a better overview of those contributors.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Wed, Apr 22, 2015 at 8:05 PM, Adam Heath <do...@brainfood.com> wrote:
>
>> On 04/22/2015 01:00 PM, Pierre Smits wrote:
>>
>>> By committers referencing the contributors to the JIRA issue in the commit
>>> report.
>>>
>> But that's not reflected in the links you provided, or users aren't
>> getting mentioned. With the git workflow, whoever created the commit will
>> *definately* be recorded, it doesn't require some free-form text message,
>> that may or may not be parsed correctly.
>>
>>
Re: move to git.
Posted by Pierre Smits <pi...@gmail.com>.
Github shows the committers as contributors. The links I provided just
shows a better overview of those contributors.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Wed, Apr 22, 2015 at 8:05 PM, Adam Heath <do...@brainfood.com> wrote:
>
> On 04/22/2015 01:00 PM, Pierre Smits wrote:
>
>> By committers referencing the contributors to the JIRA issue in the commit
>> report.
>>
>
> But that's not reflected in the links you provided, or users aren't
> getting mentioned. With the git workflow, whoever created the commit will
> *definately* be recorded, it doesn't require some free-form text message,
> that may or may not be parsed correctly.
>
>
Re: move to git.
Posted by Adam Heath <do...@brainfood.com>.
On 04/22/2015 01:00 PM, Pierre Smits wrote:
> By committers referencing the contributors to the JIRA issue in the commit
> report.
But that's not reflected in the links you provided, or users aren't
getting mentioned. With the git workflow, whoever created the commit
will *definately* be recorded, it doesn't require some free-form text
message, that may or may not be parsed correctly.
Re: move to git.
Posted by Pierre Smits <pi...@gmail.com>.
By committers referencing the contributors to the JIRA issue in the commit
report.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Wed, Apr 22, 2015 at 7:57 PM, Ean Schuessler <ea...@brainfood.com> wrote:
> > From: "Pierre Smits" <pi...@gmail.com>
> > Subject: Re: move to git.
> >
> > That, Ean, says more about github than SVN. See
> > https://fisheye6.atlassian.com/users/ofbiz and
> > https://fisheye6.atlassian.com/graph/ofbiz showing a totally different
> > story.
>
> How do I see the people who submitted patches via JIRA?
>
Re: move to git.
Posted by Ean Schuessler <ea...@brainfood.com>.
> From: "Pierre Smits" <pi...@gmail.com>
> Subject: Re: move to git.
>
> That, Ean, says more about github than SVN. See
> https://fisheye6.atlassian.com/users/ofbiz and
> https://fisheye6.atlassian.com/graph/ofbiz showing a totally different
> story.
How do I see the people who submitted patches via JIRA?
Re: move to git.
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
On Apr 27, 2015, at 3:16 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
> Thanks Ean for letting us know, I was unaware this was needed. I just added mine, but I'm still not in the contributors list, I guess it takes some time, or is another step, like joigning something, needed?
Hi Jacques, just wait, it could take some hours.
Jacopo
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 22/04/2015 19:31, Ean Schuessler a écrit :
> That raises another irritating thing about the JIRA SVN workflow vs GIT
> pull requests.
>
> If you look at the contributor graph on GitHub for OFBiz you will see
> that it currently has only 3 contributors. Foremost this is because the
> project committers have mostly not configured their Apache addresses into
> their GitHub accounts.
Thanks Ean for letting us know, I was unaware this was needed. I just added mine, but I'm still not in the contributors list, I guess it takes some
time, or is another step, like joigning something, needed?
Something I'd like to add here. Github is using the successful Freemium business model http://en.wikipedia.org/wiki/Freemium. I doubt there will ever
be issues with that, but you never know, see what happened to Apache-Extra ...
I know I can trust the ASF, even if, like everything else, it could disappear, that's even less likely than Github in foreseeable future. We live in a
disruptive world...
Jacques
> Secondly, however, it is caused by the fact that
> all JIRA committed patches will show the name of the person who merged
> the patch rather than its original author.
>
> https://github.com/apache/ofbiz/graphs/contributors
>
> We can make up stories about why this is desirable but I think any honest
> assessment would conclude that it is an inconvenience at best and a hazard
> at worst. Eventually if these dots are not connected the origins of some
> OFBiz code could become as mysterious as the early CVS commits. With the
> GIT pull request workflow we would not only know who wrote the code but
> would still know who performed the merge. We could also sign the commits
> so that their origin is cryptographically confirmed.
>
> ----- Original Message -----
>> From: "Gil Portenseigne" <gi...@nereide.fr>
>> Subject: Re: move to git.
>> Yes, but these are commiters contributions, i mean non-commiters one should go
>> thru jira.
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 28/04/2015 16:48, Adam Heath a écrit :
> Something about the 3 laws
I'm more a Philip K. Dick aficionado, I believe robots will not follow the laws at some point, hu are we serious? ;D
Jacques
Re: move to git.
Posted by Adam Heath <do...@brainfood.com>.
On 04/28/2015 03:39 AM, Jacques Le Roux wrote:
> Le 25/04/2015 01:14, Adam Heath a écrit :
>>
>> On 04/23/2015 06:00 PM, David E. Jones wrote:
>>> An FYI for all committers: create an account on GitHub (if you don't
>>> already have one) and add your @apache.org email address to it, and
>>> within a few hours you'll show up in the contributor graphs. I tried
>>> this and am now showing up there:
>>>
>>> https://github.com/apache/ofbiz/graphs/contributors
>>>
>>> If nothing else it's entertaining, I had no idea that I had this
>>> volume of commits since OFBiz joined the ASF (750k lines added, 135k
>>> lines removed; note that changes to lines show up in both counts).
>>
>> Come on, everyone. It's a competition! See if you can beat Jacopo!
>
> No chances, guys, you are far behind me :D
>
I was waiting for you to do that; I already new you were way out in
front. I saw it last night. You're a machine(I mean that in the nicest
way).
>>
>> Useless metrics are fun sometimes. Number of commits, number of
>> lines added/removed, don't really mean anything. I've seen stupid
>> code that had the same 30 lines cut and pasted 20 times, instead of
>> making a helper method, and of course a single line per commit can
>> also inflate numbers.
>
> Yes, hence my comments about quality and quantity, big data and our
> world ;)
>
>> But, it's fun to play with gui graph libraries.
>>
>>
>
> What are we w/o fun? I dare to ask the question ;)
>
> Jacques
> PS: robots will do better...
Something about the 3 laws?
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 25/04/2015 01:14, Adam Heath a écrit :
>
> On 04/23/2015 06:00 PM, David E. Jones wrote:
>> An FYI for all committers: create an account on GitHub (if you don't already have one) and add your @apache.org email address to it, and within a
>> few hours you'll show up in the contributor graphs. I tried this and am now showing up there:
>>
>> https://github.com/apache/ofbiz/graphs/contributors
>>
>> If nothing else it's entertaining, I had no idea that I had this volume of commits since OFBiz joined the ASF (750k lines added, 135k lines
>> removed; note that changes to lines show up in both counts).
>
> Come on, everyone. It's a competition! See if you can beat Jacopo!
No chances, guys, you are far behind me :D
>
> Useless metrics are fun sometimes. Number of commits, number of lines added/removed, don't really mean anything. I've seen stupid code that had
> the same 30 lines cut and pasted 20 times, instead of making a helper method, and of course a single line per commit can also inflate numbers.
Yes, hence my comments about quality and quantity, big data and our world ;)
> But, it's fun to play with gui graph libraries.
>
>
What are we w/o fun? I dare to ask the question ;)
Jacques
PS: robots will do better...
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 25/04/2015 10:23, Pierre Smits a écrit :
> Creating the JIRA issue(s) early - not just after the commit, as a
> notification for release notes - will help increasing the awareness of all
> and opens the door to share insights before the commit and not after. Give
> the issue its obligatory waiting period (72 hrs) before the commit and due
> process is ensured.
+1, I can't emphasize that more
Jacques
Re: move to git.
Posted by Taher Alkhateeb <sl...@gmail.com>.
For anyone who is interested and didn't read this before regarding git and svn comparisons:
https://git.wiki.kernel.org/index.php/GitSvnComparsion
----- Original Message -----
From: "Pierre Smits" <pi...@gmail.com>
To: dev@ofbiz.apache.org
Sent: Saturday, 25 April, 2015 11:23:26 AM
Subject: Re: move to git.
According to this presentation regarding the Apache Way
http://events.linuxfoundation.org/sites/events/files/slides/TheApacheWay15.pdf
(slides 30-31) all contributions are considered equal. That means the big,
the small, those of minor and major importance.
Nevertheless, collaborating early and often will ensure that both noise and
reverts are minimised. It can't be avoided that, with all contributors
being volunteers with limited time available , a change is committed
(accepted by lazy consensus) whereby over a period of time increase in
insights will lead to reverts of old code and to replacement by better
code.
Creating the JIRA issue(s) early - not just after the commit, as a
notification for release notes - will help increasing the awareness of all
and opens the door to share insights before the commit and not after. Give
the issue its obligatory waiting period (72 hrs) before the commit and due
process is ensured.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Sat, Apr 25, 2015 at 9:52 AM, Jacopo Cappellato <
jacopo.cappellato@hotwaxsystems.com> wrote:
>
> On Apr 25, 2015, at 1:14 AM, Adam Heath <do...@brainfood.com> wrote:
>
> > On 04/23/2015 06:00 PM, David E. Jones wrote:
> >> An FYI for all committers: create an account on GitHub (if you don't
> already have one) and add your @apache.org email address to it, and
> within a few hours you'll show up in the contributor graphs. I tried this
> and am now showing up there:
> >>
> >> https://github.com/apache/ofbiz/graphs/contributors
> >>
> >> If nothing else it's entertaining, I had no idea that I had this volume
> of commits since OFBiz joined the ASF (750k lines added, 135k lines
> removed; note that changes to lines show up in both counts).
> >
> > Come on, everyone. It's a competition! See if you can beat Jacopo!
>
> :-)
> Frankly speaking... I hates these and similar metrics (e.g. number of
> posts in the mailing list per author, number of commits per author etc...)
> because they don't say anything about the quality of the contribution but
> just on the amount of noise produced; and I am worried that they may induce
> some to post more and more, commit more and more to stay up in the ranking
> and this may be detrimental to the quality of the contribution.
>
> >
> > Useless metrics are fun sometimes. Number of commits, number of lines
> added/removed, don't really mean anything. I've seen stupid code that had
> the same 30 lines cut and pasted 20 times, instead of making a helper
> method, and of course a single line per commit can also inflate numbers.
>
> Right, or several commits then reverted :-)
>
> Jacopo
Re: move to git.
Posted by Pierre Smits <pi...@gmail.com>.
According to this presentation regarding the Apache Way
http://events.linuxfoundation.org/sites/events/files/slides/TheApacheWay15.pdf
(slides 30-31) all contributions are considered equal. That means the big,
the small, those of minor and major importance.
Nevertheless, collaborating early and often will ensure that both noise and
reverts are minimised. It can't be avoided that, with all contributors
being volunteers with limited time available , a change is committed
(accepted by lazy consensus) whereby over a period of time increase in
insights will lead to reverts of old code and to replacement by better
code.
Creating the JIRA issue(s) early - not just after the commit, as a
notification for release notes - will help increasing the awareness of all
and opens the door to share insights before the commit and not after. Give
the issue its obligatory waiting period (72 hrs) before the commit and due
process is ensured.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Sat, Apr 25, 2015 at 9:52 AM, Jacopo Cappellato <
jacopo.cappellato@hotwaxsystems.com> wrote:
>
> On Apr 25, 2015, at 1:14 AM, Adam Heath <do...@brainfood.com> wrote:
>
> > On 04/23/2015 06:00 PM, David E. Jones wrote:
> >> An FYI for all committers: create an account on GitHub (if you don't
> already have one) and add your @apache.org email address to it, and
> within a few hours you'll show up in the contributor graphs. I tried this
> and am now showing up there:
> >>
> >> https://github.com/apache/ofbiz/graphs/contributors
> >>
> >> If nothing else it's entertaining, I had no idea that I had this volume
> of commits since OFBiz joined the ASF (750k lines added, 135k lines
> removed; note that changes to lines show up in both counts).
> >
> > Come on, everyone. It's a competition! See if you can beat Jacopo!
>
> :-)
> Frankly speaking... I hates these and similar metrics (e.g. number of
> posts in the mailing list per author, number of commits per author etc...)
> because they don't say anything about the quality of the contribution but
> just on the amount of noise produced; and I am worried that they may induce
> some to post more and more, commit more and more to stay up in the ranking
> and this may be detrimental to the quality of the contribution.
>
> >
> > Useless metrics are fun sometimes. Number of commits, number of lines
> added/removed, don't really mean anything. I've seen stupid code that had
> the same 30 lines cut and pasted 20 times, instead of making a helper
> method, and of course a single line per commit can also inflate numbers.
>
> Right, or several commits then reverted :-)
>
> Jacopo
Re: move to git.
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
On Apr 25, 2015, at 1:14 AM, Adam Heath <do...@brainfood.com> wrote:
> On 04/23/2015 06:00 PM, David E. Jones wrote:
>> An FYI for all committers: create an account on GitHub (if you don't already have one) and add your @apache.org email address to it, and within a few hours you'll show up in the contributor graphs. I tried this and am now showing up there:
>>
>> https://github.com/apache/ofbiz/graphs/contributors
>>
>> If nothing else it's entertaining, I had no idea that I had this volume of commits since OFBiz joined the ASF (750k lines added, 135k lines removed; note that changes to lines show up in both counts).
>
> Come on, everyone. It's a competition! See if you can beat Jacopo!
:-)
Frankly speaking... I hates these and similar metrics (e.g. number of posts in the mailing list per author, number of commits per author etc...) because they don't say anything about the quality of the contribution but just on the amount of noise produced; and I am worried that they may induce some to post more and more, commit more and more to stay up in the ranking and this may be detrimental to the quality of the contribution.
>
> Useless metrics are fun sometimes. Number of commits, number of lines added/removed, don't really mean anything. I've seen stupid code that had the same 30 lines cut and pasted 20 times, instead of making a helper method, and of course a single line per commit can also inflate numbers.
Right, or several commits then reverted :-)
Jacopo
Re: move to git.
Posted by Adam Heath <do...@brainfood.com>.
On 04/23/2015 06:00 PM, David E. Jones wrote:
> An FYI for all committers: create an account on GitHub (if you don't already have one) and add your @apache.org email address to it, and within a few hours you'll show up in the contributor graphs. I tried this and am now showing up there:
>
> https://github.com/apache/ofbiz/graphs/contributors
>
> If nothing else it's entertaining, I had no idea that I had this volume of commits since OFBiz joined the ASF (750k lines added, 135k lines removed; note that changes to lines show up in both counts).
Come on, everyone. It's a competition! See if you can beat Jacopo!
Useless metrics are fun sometimes. Number of commits, number of lines
added/removed, don't really mean anything. I've seen stupid code that
had the same 30 lines cut and pasted 20 times, instead of making a
helper method, and of course a single line per commit can also inflate
numbers.
But, it's fun to play with gui graph libraries.
Re: move to git.
Posted by Adam Heath <do...@brainfood.com>.
On 04/23/2015 06:00 PM, David E. Jones wrote:
> An FYI for all committers: create an account on GitHub (if you don't already have one) and add your @apache.org email address to it, and within a few hours you'll show up in the contributor graphs. I tried this and am now showing up there:
>
> https://github.com/apache/ofbiz/graphs/contributors
>
> If nothing else it's entertaining, I had no idea that I had this volume of commits since OFBiz joined the ASF (750k lines added, 135k lines removed; note that changes to lines show up in both counts).
I only did this myself yesterday, after Ean mentioned it. I've actually
been on github for a bit now. But, with my @apache.org email attached
to my account, it might actually improve my standings.
FYI, I believe that large spike that is at the start of my graph(I'm
eigood, which is doogie backwards), is when I was committing the
generics markup.
> On a side note, my commit count is relatively low... ie most commits with a larger number of changes. I remember working more than way before using git... perhaps with its explicit approach to saying which files to include it encourages that more (unless you use git commit -a), or perhaps for other reasons my habits have changed.
It's not just that you can selectively pick which files; git add -i
allows you to selectively choose chunks.
> I don't get nearly as fancy as what Adam described recently with his rebase approach, but to his point I find my commits being much cleaner and better organized.
I split up my work into smaller commits(lines-per-commit is smaller), so
that it allows others to review it easier.
> -David
Re: move to git.
Posted by "David E. Jones" <de...@me.com>.
An FYI for all committers: create an account on GitHub (if you don't already have one) and add your @apache.org email address to it, and within a few hours you'll show up in the contributor graphs. I tried this and am now showing up there:
https://github.com/apache/ofbiz/graphs/contributors
If nothing else it's entertaining, I had no idea that I had this volume of commits since OFBiz joined the ASF (750k lines added, 135k lines removed; note that changes to lines show up in both counts).
On a side note, my commit count is relatively low... ie most commits with a larger number of changes. I remember working more than way before using git... perhaps with its explicit approach to saying which files to include it encourages that more (unless you use git commit -a), or perhaps for other reasons my habits have changed.
I don't get nearly as fancy as what Adam described recently with his rebase approach, but to his point I find my commits being much cleaner and better organized.
-David
> On 22 Apr 2015, at 10:31, Ean Schuessler <ea...@brainfood.com> wrote:
>
> That raises another irritating thing about the JIRA SVN workflow vs GIT
> pull requests.
>
> If you look at the contributor graph on GitHub for OFBiz you will see
> that it currently has only 3 contributors. Foremost this is because the
> project committers have mostly not configured their Apache addresses into
> their GitHub accounts. Secondly, however, it is caused by the fact that
> all JIRA committed patches will show the name of the person who merged
> the patch rather than its original author.
>
> https://github.com/apache/ofbiz/graphs/contributors
>
> We can make up stories about why this is desirable but I think any honest
> assessment would conclude that it is an inconvenience at best and a hazard
> at worst. Eventually if these dots are not connected the origins of some
> OFBiz code could become as mysterious as the early CVS commits. With the
> GIT pull request workflow we would not only know who wrote the code but
> would still know who performed the merge. We could also sign the commits
> so that their origin is cryptographically confirmed.
>
> ----- Original Message -----
>> From: "Gil Portenseigne" <gi...@nereide.fr>
>> Subject: Re: move to git.
>
>> Yes, but these are commiters contributions, i mean non-commiters one should go
>> thru jira.
Re: move to git.
Posted by Pierre Smits <pi...@gmail.com>.
That, Ean, says more about github than SVN. See
https://fisheye6.atlassian.com/users/ofbiz and
https://fisheye6.atlassian.com/graph/ofbiz showing a totally different
story.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Wed, Apr 22, 2015 at 7:31 PM, Ean Schuessler <ea...@brainfood.com> wrote:
> That raises another irritating thing about the JIRA SVN workflow vs GIT
> pull requests.
>
> If you look at the contributor graph on GitHub for OFBiz you will see
> that it currently has only 3 contributors. Foremost this is because the
> project committers have mostly not configured their Apache addresses into
> their GitHub accounts. Secondly, however, it is caused by the fact that
> all JIRA committed patches will show the name of the person who merged
> the patch rather than its original author.
>
> https://github.com/apache/ofbiz/graphs/contributors
>
> We can make up stories about why this is desirable but I think any honest
> assessment would conclude that it is an inconvenience at best and a hazard
> at worst. Eventually if these dots are not connected the origins of some
> OFBiz code could become as mysterious as the early CVS commits. With the
> GIT pull request workflow we would not only know who wrote the code but
> would still know who performed the merge. We could also sign the commits
> so that their origin is cryptographically confirmed.
>
> ----- Original Message -----
> > From: "Gil Portenseigne" <gi...@nereide.fr>
> > Subject: Re: move to git.
>
> > Yes, but these are commiters contributions, i mean non-commiters one
> should go
> > thru jira.
>
Re: move to git.
Posted by "David E. Jones" <de...@me.com>.
Tracking the original contributor is an important point.
The nice thing about git is that every commit has a UUID so even as that commit is pulled from one repository to another the contributor and other details can be tracked. In SVN as things go from one repo to another this is lost (unless it's something like a full repository import).
-David
> On 22 Apr 2015, at 10:31, Ean Schuessler <ea...@brainfood.com> wrote:
>
> That raises another irritating thing about the JIRA SVN workflow vs GIT
> pull requests.
>
> If you look at the contributor graph on GitHub for OFBiz you will see
> that it currently has only 3 contributors. Foremost this is because the
> project committers have mostly not configured their Apache addresses into
> their GitHub accounts. Secondly, however, it is caused by the fact that
> all JIRA committed patches will show the name of the person who merged
> the patch rather than its original author.
>
> https://github.com/apache/ofbiz/graphs/contributors
>
> We can make up stories about why this is desirable but I think any honest
> assessment would conclude that it is an inconvenience at best and a hazard
> at worst. Eventually if these dots are not connected the origins of some
> OFBiz code could become as mysterious as the early CVS commits. With the
> GIT pull request workflow we would not only know who wrote the code but
> would still know who performed the merge. We could also sign the commits
> so that their origin is cryptographically confirmed.
>
> ----- Original Message -----
>> From: "Gil Portenseigne" <gi...@nereide.fr>
>> Subject: Re: move to git.
>
>> Yes, but these are commiters contributions, i mean non-commiters one should go
>> thru jira.
Re: move to git.
Posted by Ean Schuessler <ea...@brainfood.com>.
That raises another irritating thing about the JIRA SVN workflow vs GIT
pull requests.
If you look at the contributor graph on GitHub for OFBiz you will see
that it currently has only 3 contributors. Foremost this is because the
project committers have mostly not configured their Apache addresses into
their GitHub accounts. Secondly, however, it is caused by the fact that
all JIRA committed patches will show the name of the person who merged
the patch rather than its original author.
https://github.com/apache/ofbiz/graphs/contributors
We can make up stories about why this is desirable but I think any honest
assessment would conclude that it is an inconvenience at best and a hazard
at worst. Eventually if these dots are not connected the origins of some
OFBiz code could become as mysterious as the early CVS commits. With the
GIT pull request workflow we would not only know who wrote the code but
would still know who performed the merge. We could also sign the commits
so that their origin is cryptographically confirmed.
----- Original Message -----
> From: "Gil Portenseigne" <gi...@nereide.fr>
> Subject: Re: move to git.
> Yes, but these are commiters contributions, i mean non-commiters one should go
> thru jira.
Re: move to git.
Posted by Gil Portenseigne <gi...@nereide.fr>.
Yes, but these are commiters contributions, i mean non-commiters one should go thru jira.
Le 21 avril 2015 23:00:26 UTC+02:00, Adam Heath <do...@brainfood.com> a écrit :
>
>On 04/21/2015 08:09 AM, Gil portenseigne wrote:
>>
>> In every case, contribution will have to be given within Jira to get
>> into the project.
>>
>
>This is not the case even today. I see changes in the svn log that
>have
>no jira issue.
Re: move to git.
Posted by Adam Heath <do...@brainfood.com>.
On 04/21/2015 08:09 AM, Gil portenseigne wrote:
>
> In every case, contribution will have to be given within Jira to get
> into the project.
>
This is not the case even today. I see changes in the svn log that have
no jira issue.
Re: move to git.
Posted by gil portenseigne <gi...@nereide.fr>.
Yeah Jacques, i got your point, but clarification was needed to avoid
the assimilation of Nereide and OFBiz-France association (no lobbying or
so).
Clearly if Git is adopted (even if not I guess, there is a workaround)
there will be a new way to share/maintain solution around OFBiz.
Like i said i didn't had the time to learn more about git, but from what
i read in the thread, it could be a good tool.
Gil
On 29/04/2015 14:47, Jacques Le Roux wrote:
> Thanks for taking the time to clarify Gil, I was in a hurry and did
> not put enough information, let me clarify my point.
>
> I only wanted to speak about the tool used to create, maintain and
> share extensions. For the moment the "OFBiz-France solution" (actually
> more Nereides one) is based on the patch command and the addons manager.
> The idea here was, if ever the OFBiz project would use Git instead of
> Svn, maybe the OFBiz-France solution could be based on Github and
> maintained as described below by David. Still a lot of of
> speculations, but better to think ahead even if nothing happens ;)
>
> Jacques
>
> Le 21/04/2015 15:09, Gil portenseigne a écrit :
>> Hi all,
>>
>> First to clarify things, OFBiz-france association goal is to promote
>> Apache OFBiz into french speaking audience by giving references
>> (information, classifications and links) to extensions
>> (documentations, addons, patchs or packaged solution), maybe hosting
>> some high quality not contributable extensions.
>> Helping extensions' owner improving their quality to convert its into
>> OFBiz contribution if possible, or referencing them for easy sharing
>> of classified solutions.
>> Creating a tool integrated into Apache OFBiz too manage and share
>> anyone devs by implementing a new extension manager
>> (http://ofbiz.markmail.org/message/goxbqcgurpoy2yfp?q=ofbiz-fr
>> without success for now :) )
>>
>> Nereide Leverage of addon solutions, like you introduce is just an
>> illustration of this process. Nereide as a member of the association
>> will give as example some instance of extensions, hoping that other
>> contribution and contributor will come (and be welcome).
>>
>> I think that this git solution of *creating a consortium [...]* is
>> quite different (even if i do not understand all the ins and out of
>> it) and might be more comparable to ofbizextra effort, to give the
>> ability for everyone to develop and share using a dedicated tool.
>>
>> And because everything which is committed into Apache OFBiz project
>> has to be validated, and development within Integrators Projects do
>> not have the same rythm/pace, ofbizextra was created to store and
>> share unfinished/specific/not ready quality wise devs and this has to
>> be out of Apache OFBiz.
>>
>> My personal opinion is (i'm not a git user), that SVN seems quite
>> sufficient for Apache OFBiz needs. I remind me reading that there is
>> already a git repository of the trunk branch so, if true, it can be
>> used by contributor too make their devs using it. I'm not relevent
>> evaluating git usage, but i do not feel a real problem using SVN.
>>
>> In every case, contribution will have to be given within Jira to get
>> into the project.
>>
>> Best Regards
>>
>> Gil
>>
>>
>> On 21/04/2015 12:19, Jacques Le Roux wrote:
>>>
>>> Le 21/04/2015 12:02, David E. Jones a écrit :
>>>>> On 20 Apr 2015, at 23:21, Pierre Smits <pi...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Quoting:
>>>>>
>>>>> We are also prepared to be assertive regarding this situation. If the
>>>>> project
>>>>> does not move to GIT then Brainfood is willing to participate in a
>>>>> consortium of
>>>>> organizations that will peer with each other to share updates to
>>>>> the master
>>>>> branch for their local OFBiz repository. Such an arrangement will,
>>>>> effectively,
>>>>> result in a distributed master repository image.
>>>>>
>>>>> Thanks Ean for the position of *Brainfood* in this position. It comes
>>>>> across as 'Do it our way, or else'. You are free to make such
>>>>> statements
>>>>> and when followed through there will be consequences. For all
>>>>> participating
>>>>> in this project. One I can see standing out clearly is: no more
>>>>> participation in/contribution from the employees of Brainfood and
>>>>> from the
>>>>> other companies in that consortium back into the project.
>>>> That's not at all what I get from Ean's comments. The magic of a
>>>> community-driven project is that people can collaborate on anything
>>>> they want, within the scope of the main project or as side
>>>> projects. If the main project doesn't provide something desired,
>>>> then it is perfectly appropriate for others to collaborate on
>>>> that... better than doing it totally isolated.
>>>>
>>>> What Ean is talking about ties in with the general idea of
>>>> distributed source management and distributed development. The
>>>> general idea is that there may be many forks of the main source
>>>> repo, potentially with various branches for different improvements
>>>> and changes. These are generally made available publicly, like
>>>> public GitHub forks of other public repositories (though with git
>>>> they can be hosted anywhere).
>>>>
>>>> Those who make changes can request that particular changes be
>>>> pulled into upstream repositories and then those who maintain the
>>>> upstream repos (or the main project repo if it bubbles up that
>>>> high) can review them and pull the changes if desired. Those who
>>>> maintain upstream repos can also look around for useful changes in
>>>> forked repos and pull them in as desired. Others who run their own
>>>> forks can pull in changes from peer repositories too.
>>>>
>>>> It may seem like chaos to have forks and changes spread all over
>>>> the place... but that isn't caused by the distributed source
>>>> management approach, it's just made visible and clear by the
>>>> approach. Right now this exists on a large scale for OFBiz, tons of
>>>> forks and changes in them, but they are mostly not visible or
>>>> publicly available so there is no way for OFBiz committers to pull
>>>> changes from other repos... they basically have to be extracted
>>>> into a patch file and submitted through a Jira issue.
>>>>
>>>> In other words, the chaos exists and the distributed source
>>>> management enabled by git just makes it easier to track it all and
>>>> tame it a bit.
>>>>
>>>> On a side note, this is one of the reasons I have concerns about
>>>> making Moqui and related projects part of the ASF: the ASF
>>>> community approach doesn't fit very well with this distributed
>>>> source management model (pull requests are discouraged, all
>>>> contributions should go through Jira issues... though I don't know
>>>> that this is a strict policy).
>>>>
>>>> -David
>>>
>>> Interesting David, it can be compared to the OFBiz-France
>>> association effort to leverage the Nereides addons and addons
>>> manager. I let aside the licenses issues, as long as it's no part of
>>> a released package there are no problems.
>>> What do you think OFBiz-France members?
>>>
>>> Jacques
>>>
>>>>
>>>>> If that is going to happen, I will say: 'I thank you for all the
>>>>> contributions you did to the project'. And I will check in my
>>>>> sentiments at
>>>>> the door. I do hope that if you do you also resign totally from this
>>>>> project.
>>>>>
>>>>>
>>>>> I rather have the community comes to its decision based on
>>>>> sound/valid
>>>>> arguments, not (veiled) threats.
>>>>> l
>>>>> Best regards,
>>>>>
>>>>> Pierre Smits
>>>>>
>>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>>> Services & Solutions for Cloud-
>>>>> Based Manufacturing, Professional
>>>>> Services and Retail & Trade
>>>>> http://www.orrtiz.com
>>>>>
>>>>> On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler
>>>>> <ea...@brainfood.com> wrote:
>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Jacques Le Roux" <ja...@les7arts.com>
>>>>>>> Subject: Re: move to git.
>>>>>>> Like Adrian and mostly for the same reasons, I don't believe we
>>>>>>> need Git.
>>>>>>>
>>>>>>> But there is one other major reason which has already been
>>>>>>> discussed in
>>>>>> the
>>>>>>> other common ASF MLs. As Taher exulted, it's possible to create
>>>>>>> local
>>>>>>> branches. So people are able to do a lot of work alone without
>>>>>> exchanging before
>>>>>>> committing or submitting. It will certainly not help to have this
>>>>>>> possibility.
>>>>>> I disagree. It is useful in many situations for OFBiz developers
>>>>>> to create
>>>>>> a
>>>>>> local repository that is not globally shared. Some customers may
>>>>>> even
>>>>>> require
>>>>>> such a situation for security or legal reasons.
>>>>>>
>>>>>>> Remember our recent discussion on the lack or core commits reviews.
>>>>>>> With Git you end with commits bursts or big patches and it's then
>>>>>>> hard to review and too late to share ideas.
>>>>>>>
>>>>>>> So unlike Adrian, I'm even strongly against it. I will not
>>>>>>> hesitate to
>>>>>> use a -1
>>>>>>> if necessary!
>>>>>> We are also prepared to be assertive regarding this situation. If
>>>>>> the
>>>>>> project
>>>>>> does not move to GIT then Brainfood is willing to participate in a
>>>>>> consortium of
>>>>>> organizations that will peer with each other to share updates to
>>>>>> the master
>>>>>> branch for their local OFBiz repository. Such an arrangement will,
>>>>>> effectively,
>>>>>> result in a distributed master repository image.
>>>>>>
>>>>>> If anyone else is interested in such an arrangement please feel
>>>>>> free to
>>>>>> speak
>>>>>> up and we can begin the planning process.
>>>>>>
>>>>
>>>>
>>
>>
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 29/04/2015 21:47, Adam Heath a écrit :
>
> On 04/29/2015 02:26 PM, Jacques Le Roux wrote:
>> Related to this thread but not with previous discussions, see how Github is used at the ASF https://wiki.apache.org/commons/UsingGIT ; notably for
>> "Applying Pull Requests (for svn based components)"
>>
>> Jacques
>
> Yeah, that's actually troubling. The recommended procedure for merging git changes is to apply a patch. There is no recommendation on how to
> attribute the original contributor.
>
> The next section that talks about merging github into projects that use git also doesn't mention anything about CLA of the code being merged
> either. But at least the attribution is maintained automatically.
>
>
It's OK if the "component" is in an ASF Git repo (https://git-wip-us.apache.org/repos/asf/). In the 1st section I read "In a way, the Apache committer
acts here as a proxy for the contributor, and makes sure everything is good to include. (Consequently Git can have different authors and commiters of
a commit. If pulled in as git-patch or pull request the author is preserved)."
Jacques
Re: move to git.
Posted by Adam Heath <do...@brainfood.com>.
On 04/29/2015 02:26 PM, Jacques Le Roux wrote:
> Related to this thread but not with previous discussions, see how
> Github is used at the ASF https://wiki.apache.org/commons/UsingGIT ;
> notably for "Applying Pull Requests (for svn based components)"
>
> Jacques
Yeah, that's actually troubling. The recommended procedure for merging
git changes is to apply a patch. There is no recommendation on how to
attribute the original contributor.
The next section that talks about merging github into projects that use
git also doesn't mention anything about CLA of the code being merged
either. But at least the attribution is maintained automatically.
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Related to this thread but not with previous discussions, see how Github is used at the ASF https://wiki.apache.org/commons/UsingGIT ; notably for
"Applying Pull Requests (for svn based components)"
Jacques
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Thanks for taking the time to clarify Gil, I was in a hurry and did not put enough information, let me clarify my point.
I only wanted to speak about the tool used to create, maintain and share extensions. For the moment the "OFBiz-France solution" (actually more
Nereides one) is based on the patch command and the addons manager.
The idea here was, if ever the OFBiz project would use Git instead of Svn, maybe the OFBiz-France solution could be based on Github and maintained as
described below by David. Still a lot of of speculations, but better to think ahead even if nothing happens ;)
Jacques
Le 21/04/2015 15:09, Gil portenseigne a écrit :
> Hi all,
>
> First to clarify things, OFBiz-france association goal is to promote Apache OFBiz into french speaking audience by giving references (information,
> classifications and links) to extensions (documentations, addons, patchs or packaged solution), maybe hosting some high quality not contributable
> extensions.
> Helping extensions' owner improving their quality to convert its into OFBiz contribution if possible, or referencing them for easy sharing of
> classified solutions.
> Creating a tool integrated into Apache OFBiz too manage and share anyone devs by implementing a new extension manager
> (http://ofbiz.markmail.org/message/goxbqcgurpoy2yfp?q=ofbiz-fr without success for now :) )
>
> Nereide Leverage of addon solutions, like you introduce is just an illustration of this process. Nereide as a member of the association will give as
> example some instance of extensions, hoping that other contribution and contributor will come (and be welcome).
>
> I think that this git solution of *creating a consortium [...]* is quite different (even if i do not understand all the ins and out of it) and might
> be more comparable to ofbizextra effort, to give the ability for everyone to develop and share using a dedicated tool.
>
> And because everything which is committed into Apache OFBiz project has to be validated, and development within Integrators Projects do not have the
> same rythm/pace, ofbizextra was created to store and share unfinished/specific/not ready quality wise devs and this has to be out of Apache OFBiz.
>
> My personal opinion is (i'm not a git user), that SVN seems quite sufficient for Apache OFBiz needs. I remind me reading that there is already a git
> repository of the trunk branch so, if true, it can be used by contributor too make their devs using it. I'm not relevent evaluating git usage, but i
> do not feel a real problem using SVN.
>
> In every case, contribution will have to be given within Jira to get into the project.
>
> Best Regards
>
> Gil
>
>
> On 21/04/2015 12:19, Jacques Le Roux wrote:
>>
>> Le 21/04/2015 12:02, David E. Jones a écrit :
>>>> On 20 Apr 2015, at 23:21, Pierre Smits <pi...@gmail.com> wrote:
>>>>
>>>> Quoting:
>>>>
>>>> We are also prepared to be assertive regarding this situation. If the
>>>> project
>>>> does not move to GIT then Brainfood is willing to participate in a
>>>> consortium of
>>>> organizations that will peer with each other to share updates to the master
>>>> branch for their local OFBiz repository. Such an arrangement will,
>>>> effectively,
>>>> result in a distributed master repository image.
>>>>
>>>> Thanks Ean for the position of *Brainfood* in this position. It comes
>>>> across as 'Do it our way, or else'. You are free to make such statements
>>>> and when followed through there will be consequences. For all participating
>>>> in this project. One I can see standing out clearly is: no more
>>>> participation in/contribution from the employees of Brainfood and from the
>>>> other companies in that consortium back into the project.
>>> That's not at all what I get from Ean's comments. The magic of a community-driven project is that people can collaborate on anything they want,
>>> within the scope of the main project or as side projects. If the main project doesn't provide something desired, then it is perfectly appropriate
>>> for others to collaborate on that... better than doing it totally isolated.
>>>
>>> What Ean is talking about ties in with the general idea of distributed source management and distributed development. The general idea is that
>>> there may be many forks of the main source repo, potentially with various branches for different improvements and changes. These are generally
>>> made available publicly, like public GitHub forks of other public repositories (though with git they can be hosted anywhere).
>>>
>>> Those who make changes can request that particular changes be pulled into upstream repositories and then those who maintain the upstream repos (or
>>> the main project repo if it bubbles up that high) can review them and pull the changes if desired. Those who maintain upstream repos can also look
>>> around for useful changes in forked repos and pull them in as desired. Others who run their own forks can pull in changes from peer repositories too.
>>>
>>> It may seem like chaos to have forks and changes spread all over the place... but that isn't caused by the distributed source management approach,
>>> it's just made visible and clear by the approach. Right now this exists on a large scale for OFBiz, tons of forks and changes in them, but they
>>> are mostly not visible or publicly available so there is no way for OFBiz committers to pull changes from other repos... they basically have to be
>>> extracted into a patch file and submitted through a Jira issue.
>>>
>>> In other words, the chaos exists and the distributed source management enabled by git just makes it easier to track it all and tame it a bit.
>>>
>>> On a side note, this is one of the reasons I have concerns about making Moqui and related projects part of the ASF: the ASF community approach
>>> doesn't fit very well with this distributed source management model (pull requests are discouraged, all contributions should go through Jira
>>> issues... though I don't know that this is a strict policy).
>>>
>>> -David
>>
>> Interesting David, it can be compared to the OFBiz-France association effort to leverage the Nereides addons and addons manager. I let aside the
>> licenses issues, as long as it's no part of a released package there are no problems.
>> What do you think OFBiz-France members?
>>
>> Jacques
>>
>>>
>>>> If that is going to happen, I will say: 'I thank you for all the
>>>> contributions you did to the project'. And I will check in my sentiments at
>>>> the door. I do hope that if you do you also resign totally from this
>>>> project.
>>>>
>>>>
>>>> I rather have the community comes to its decision based on sound/valid
>>>> arguments, not (veiled) threats.
>>>> l
>>>> Best regards,
>>>>
>>>> Pierre Smits
>>>>
>>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>>> Services & Solutions for Cloud-
>>>> Based Manufacturing, Professional
>>>> Services and Retail & Trade
>>>> http://www.orrtiz.com
>>>>
>>>> On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler <ea...@brainfood.com> wrote:
>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Jacques Le Roux" <ja...@les7arts.com>
>>>>>> Subject: Re: move to git.
>>>>>> Like Adrian and mostly for the same reasons, I don't believe we need Git.
>>>>>>
>>>>>> But there is one other major reason which has already been discussed in
>>>>> the
>>>>>> other common ASF MLs. As Taher exulted, it's possible to create local
>>>>>> branches. So people are able to do a lot of work alone without
>>>>> exchanging before
>>>>>> committing or submitting. It will certainly not help to have this
>>>>>> possibility.
>>>>> I disagree. It is useful in many situations for OFBiz developers to create
>>>>> a
>>>>> local repository that is not globally shared. Some customers may even
>>>>> require
>>>>> such a situation for security or legal reasons.
>>>>>
>>>>>> Remember our recent discussion on the lack or core commits reviews.
>>>>>> With Git you end with commits bursts or big patches and it's then
>>>>>> hard to review and too late to share ideas.
>>>>>>
>>>>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>>>>> use a -1
>>>>>> if necessary!
>>>>> We are also prepared to be assertive regarding this situation. If the
>>>>> project
>>>>> does not move to GIT then Brainfood is willing to participate in a
>>>>> consortium of
>>>>> organizations that will peer with each other to share updates to the master
>>>>> branch for their local OFBiz repository. Such an arrangement will,
>>>>> effectively,
>>>>> result in a distributed master repository image.
>>>>>
>>>>> If anyone else is interested in such an arrangement please feel free to
>>>>> speak
>>>>> up and we can begin the planning process.
>>>>>
>>>
>>>
>
>
Re: move to git.
Posted by Gil portenseigne <gi...@nereide.fr>.
Hi all,
First to clarify things, OFBiz-france association goal is to promote
Apache OFBiz into french speaking audience by giving references
(information, classifications and links) to extensions (documentations,
addons, patchs or packaged solution), maybe hosting some high quality
not contributable extensions.
Helping extensions' owner improving their quality to convert its into
OFBiz contribution if possible, or referencing them for easy sharing of
classified solutions.
Creating a tool integrated into Apache OFBiz too manage and share anyone
devs by implementing a new extension manager
(http://ofbiz.markmail.org/message/goxbqcgurpoy2yfp?q=ofbiz-fr without
success for now :) )
Nereide Leverage of addon solutions, like you introduce is just an
illustration of this process. Nereide as a member of the association
will give as example some instance of extensions, hoping that other
contribution and contributor will come (and be welcome).
I think that this git solution of *creating a consortium [...]* is quite
different (even if i do not understand all the ins and out of it) and
might be more comparable to ofbizextra effort, to give the ability for
everyone to develop and share using a dedicated tool.
And because everything which is committed into Apache OFBiz project has
to be validated, and development within Integrators Projects do not have
the same rythm/pace, ofbizextra was created to store and share
unfinished/specific/not ready quality wise devs and this has to be out
of Apache OFBiz.
My personal opinion is (i'm not a git user), that SVN seems quite
sufficient for Apache OFBiz needs. I remind me reading that there is
already a git repository of the trunk branch so, if true, it can be used
by contributor too make their devs using it. I'm not relevent evaluating
git usage, but i do not feel a real problem using SVN.
In every case, contribution will have to be given within Jira to get
into the project.
Best Regards
Gil
On 21/04/2015 12:19, Jacques Le Roux wrote:
>
> Le 21/04/2015 12:02, David E. Jones a écrit :
>>> On 20 Apr 2015, at 23:21, Pierre Smits <pi...@gmail.com> wrote:
>>>
>>> Quoting:
>>>
>>> We are also prepared to be assertive regarding this situation. If the
>>> project
>>> does not move to GIT then Brainfood is willing to participate in a
>>> consortium of
>>> organizations that will peer with each other to share updates to the
>>> master
>>> branch for their local OFBiz repository. Such an arrangement will,
>>> effectively,
>>> result in a distributed master repository image.
>>>
>>> Thanks Ean for the position of *Brainfood* in this position. It comes
>>> across as 'Do it our way, or else'. You are free to make such
>>> statements
>>> and when followed through there will be consequences. For all
>>> participating
>>> in this project. One I can see standing out clearly is: no more
>>> participation in/contribution from the employees of Brainfood and
>>> from the
>>> other companies in that consortium back into the project.
>> That's not at all what I get from Ean's comments. The magic of a
>> community-driven project is that people can collaborate on anything
>> they want, within the scope of the main project or as side projects.
>> If the main project doesn't provide something desired, then it is
>> perfectly appropriate for others to collaborate on that... better
>> than doing it totally isolated.
>>
>> What Ean is talking about ties in with the general idea of
>> distributed source management and distributed development. The
>> general idea is that there may be many forks of the main source repo,
>> potentially with various branches for different improvements and
>> changes. These are generally made available publicly, like public
>> GitHub forks of other public repositories (though with git they can
>> be hosted anywhere).
>>
>> Those who make changes can request that particular changes be pulled
>> into upstream repositories and then those who maintain the upstream
>> repos (or the main project repo if it bubbles up that high) can
>> review them and pull the changes if desired. Those who maintain
>> upstream repos can also look around for useful changes in forked
>> repos and pull them in as desired. Others who run their own forks can
>> pull in changes from peer repositories too.
>>
>> It may seem like chaos to have forks and changes spread all over the
>> place... but that isn't caused by the distributed source management
>> approach, it's just made visible and clear by the approach. Right now
>> this exists on a large scale for OFBiz, tons of forks and changes in
>> them, but they are mostly not visible or publicly available so there
>> is no way for OFBiz committers to pull changes from other repos...
>> they basically have to be extracted into a patch file and submitted
>> through a Jira issue.
>>
>> In other words, the chaos exists and the distributed source
>> management enabled by git just makes it easier to track it all and
>> tame it a bit.
>>
>> On a side note, this is one of the reasons I have concerns about
>> making Moqui and related projects part of the ASF: the ASF community
>> approach doesn't fit very well with this distributed source
>> management model (pull requests are discouraged, all contributions
>> should go through Jira issues... though I don't know that this is a
>> strict policy).
>>
>> -David
>
> Interesting David, it can be compared to the OFBiz-France association
> effort to leverage the Nereides addons and addons manager. I let aside
> the licenses issues, as long as it's no part of a released package
> there are no problems.
> What do you think OFBiz-France members?
>
> Jacques
>
>>
>>> If that is going to happen, I will say: 'I thank you for all the
>>> contributions you did to the project'. And I will check in my
>>> sentiments at
>>> the door. I do hope that if you do you also resign totally from this
>>> project.
>>>
>>>
>>> I rather have the community comes to its decision based on sound/valid
>>> arguments, not (veiled) threats.
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM <http://www.orrtiz.com>*
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler <ea...@brainfood.com>
>>> wrote:
>>>
>>>> ----- Original Message -----
>>>>> From: "Jacques Le Roux" <ja...@les7arts.com>
>>>>> Subject: Re: move to git.
>>>>> Like Adrian and mostly for the same reasons, I don't believe we
>>>>> need Git.
>>>>>
>>>>> But there is one other major reason which has already been
>>>>> discussed in
>>>> the
>>>>> other common ASF MLs. As Taher exulted, it's possible to create
>>>>> local
>>>>> branches. So people are able to do a lot of work alone without
>>>> exchanging before
>>>>> committing or submitting. It will certainly not help to have this
>>>>> possibility.
>>>> I disagree. It is useful in many situations for OFBiz developers to
>>>> create
>>>> a
>>>> local repository that is not globally shared. Some customers may even
>>>> require
>>>> such a situation for security or legal reasons.
>>>>
>>>>> Remember our recent discussion on the lack or core commits reviews.
>>>>> With Git you end with commits bursts or big patches and it's then
>>>>> hard to review and too late to share ideas.
>>>>>
>>>>> So unlike Adrian, I'm even strongly against it. I will not
>>>>> hesitate to
>>>> use a -1
>>>>> if necessary!
>>>> We are also prepared to be assertive regarding this situation. If the
>>>> project
>>>> does not move to GIT then Brainfood is willing to participate in a
>>>> consortium of
>>>> organizations that will peer with each other to share updates to
>>>> the master
>>>> branch for their local OFBiz repository. Such an arrangement will,
>>>> effectively,
>>>> result in a distributed master repository image.
>>>>
>>>> If anyone else is interested in such an arrangement please feel
>>>> free to
>>>> speak
>>>> up and we can begin the planning process.
>>>>
>>
>>
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 21/04/2015 12:02, David E. Jones a écrit :
>> On 20 Apr 2015, at 23:21, Pierre Smits <pi...@gmail.com> wrote:
>>
>> Quoting:
>>
>> We are also prepared to be assertive regarding this situation. If the
>> project
>> does not move to GIT then Brainfood is willing to participate in a
>> consortium of
>> organizations that will peer with each other to share updates to the master
>> branch for their local OFBiz repository. Such an arrangement will,
>> effectively,
>> result in a distributed master repository image.
>>
>> Thanks Ean for the position of *Brainfood* in this position. It comes
>> across as 'Do it our way, or else'. You are free to make such statements
>> and when followed through there will be consequences. For all participating
>> in this project. One I can see standing out clearly is: no more
>> participation in/contribution from the employees of Brainfood and from the
>> other companies in that consortium back into the project.
> That's not at all what I get from Ean's comments. The magic of a community-driven project is that people can collaborate on anything they want, within the scope of the main project or as side projects. If the main project doesn't provide something desired, then it is perfectly appropriate for others to collaborate on that... better than doing it totally isolated.
>
> What Ean is talking about ties in with the general idea of distributed source management and distributed development. The general idea is that there may be many forks of the main source repo, potentially with various branches for different improvements and changes. These are generally made available publicly, like public GitHub forks of other public repositories (though with git they can be hosted anywhere).
>
> Those who make changes can request that particular changes be pulled into upstream repositories and then those who maintain the upstream repos (or the main project repo if it bubbles up that high) can review them and pull the changes if desired. Those who maintain upstream repos can also look around for useful changes in forked repos and pull them in as desired. Others who run their own forks can pull in changes from peer repositories too.
>
> It may seem like chaos to have forks and changes spread all over the place... but that isn't caused by the distributed source management approach, it's just made visible and clear by the approach. Right now this exists on a large scale for OFBiz, tons of forks and changes in them, but they are mostly not visible or publicly available so there is no way for OFBiz committers to pull changes from other repos... they basically have to be extracted into a patch file and submitted through a Jira issue.
>
> In other words, the chaos exists and the distributed source management enabled by git just makes it easier to track it all and tame it a bit.
>
> On a side note, this is one of the reasons I have concerns about making Moqui and related projects part of the ASF: the ASF community approach doesn't fit very well with this distributed source management model (pull requests are discouraged, all contributions should go through Jira issues... though I don't know that this is a strict policy).
>
> -David
Interesting David, it can be compared to the OFBiz-France association effort to leverage the Nereides addons and addons manager. I let aside the
licenses issues, as long as it's no part of a released package there are no problems.
What do you think OFBiz-France members?
Jacques
>
>> If that is going to happen, I will say: 'I thank you for all the
>> contributions you did to the project'. And I will check in my sentiments at
>> the door. I do hope that if you do you also resign totally from this
>> project.
>>
>>
>> I rather have the community comes to its decision based on sound/valid
>> arguments, not (veiled) threats.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM <http://www.orrtiz.com>*
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler <ea...@brainfood.com> wrote:
>>
>>> ----- Original Message -----
>>>> From: "Jacques Le Roux" <ja...@les7arts.com>
>>>> Subject: Re: move to git.
>>>> Like Adrian and mostly for the same reasons, I don't believe we need Git.
>>>>
>>>> But there is one other major reason which has already been discussed in
>>> the
>>>> other common ASF MLs. As Taher exulted, it's possible to create local
>>>> branches. So people are able to do a lot of work alone without
>>> exchanging before
>>>> committing or submitting. It will certainly not help to have this
>>>> possibility.
>>> I disagree. It is useful in many situations for OFBiz developers to create
>>> a
>>> local repository that is not globally shared. Some customers may even
>>> require
>>> such a situation for security or legal reasons.
>>>
>>>> Remember our recent discussion on the lack or core commits reviews.
>>>> With Git you end with commits bursts or big patches and it's then
>>>> hard to review and too late to share ideas.
>>>>
>>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>>> use a -1
>>>> if necessary!
>>> We are also prepared to be assertive regarding this situation. If the
>>> project
>>> does not move to GIT then Brainfood is willing to participate in a
>>> consortium of
>>> organizations that will peer with each other to share updates to the master
>>> branch for their local OFBiz repository. Such an arrangement will,
>>> effectively,
>>> result in a distributed master repository image.
>>>
>>> If anyone else is interested in such an arrangement please feel free to
>>> speak
>>> up and we can begin the planning process.
>>>
>
>
Re: move to git.
Posted by "David E. Jones" <de...@me.com>.
> On 20 Apr 2015, at 23:21, Pierre Smits <pi...@gmail.com> wrote:
>
> Quoting:
>
> We are also prepared to be assertive regarding this situation. If the
> project
> does not move to GIT then Brainfood is willing to participate in a
> consortium of
> organizations that will peer with each other to share updates to the master
> branch for their local OFBiz repository. Such an arrangement will,
> effectively,
> result in a distributed master repository image.
>
> Thanks Ean for the position of *Brainfood* in this position. It comes
> across as 'Do it our way, or else'. You are free to make such statements
> and when followed through there will be consequences. For all participating
> in this project. One I can see standing out clearly is: no more
> participation in/contribution from the employees of Brainfood and from the
> other companies in that consortium back into the project.
That's not at all what I get from Ean's comments. The magic of a community-driven project is that people can collaborate on anything they want, within the scope of the main project or as side projects. If the main project doesn't provide something desired, then it is perfectly appropriate for others to collaborate on that... better than doing it totally isolated.
What Ean is talking about ties in with the general idea of distributed source management and distributed development. The general idea is that there may be many forks of the main source repo, potentially with various branches for different improvements and changes. These are generally made available publicly, like public GitHub forks of other public repositories (though with git they can be hosted anywhere).
Those who make changes can request that particular changes be pulled into upstream repositories and then those who maintain the upstream repos (or the main project repo if it bubbles up that high) can review them and pull the changes if desired. Those who maintain upstream repos can also look around for useful changes in forked repos and pull them in as desired. Others who run their own forks can pull in changes from peer repositories too.
It may seem like chaos to have forks and changes spread all over the place... but that isn't caused by the distributed source management approach, it's just made visible and clear by the approach. Right now this exists on a large scale for OFBiz, tons of forks and changes in them, but they are mostly not visible or publicly available so there is no way for OFBiz committers to pull changes from other repos... they basically have to be extracted into a patch file and submitted through a Jira issue.
In other words, the chaos exists and the distributed source management enabled by git just makes it easier to track it all and tame it a bit.
On a side note, this is one of the reasons I have concerns about making Moqui and related projects part of the ASF: the ASF community approach doesn't fit very well with this distributed source management model (pull requests are discouraged, all contributions should go through Jira issues... though I don't know that this is a strict policy).
-David
> If that is going to happen, I will say: 'I thank you for all the
> contributions you did to the project'. And I will check in my sentiments at
> the door. I do hope that if you do you also resign totally from this
> project.
>
>
> I rather have the community comes to its decision based on sound/valid
> arguments, not (veiled) threats.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler <ea...@brainfood.com> wrote:
>
>> ----- Original Message -----
>>> From: "Jacques Le Roux" <ja...@les7arts.com>
>>> Subject: Re: move to git.
>>
>>> Like Adrian and mostly for the same reasons, I don't believe we need Git.
>>>
>>> But there is one other major reason which has already been discussed in
>> the
>>> other common ASF MLs. As Taher exulted, it's possible to create local
>>> branches. So people are able to do a lot of work alone without
>> exchanging before
>>> committing or submitting. It will certainly not help to have this
>>> possibility.
>>
>> I disagree. It is useful in many situations for OFBiz developers to create
>> a
>> local repository that is not globally shared. Some customers may even
>> require
>> such a situation for security or legal reasons.
>>
>>> Remember our recent discussion on the lack or core commits reviews.
>>> With Git you end with commits bursts or big patches and it's then
>>> hard to review and too late to share ideas.
>>>
>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>> use a -1
>>> if necessary!
>>
>> We are also prepared to be assertive regarding this situation. If the
>> project
>> does not move to GIT then Brainfood is willing to participate in a
>> consortium of
>> organizations that will peer with each other to share updates to the master
>> branch for their local OFBiz repository. Such an arrangement will,
>> effectively,
>> result in a distributed master repository image.
>>
>> If anyone else is interested in such an arrangement please feel free to
>> speak
>> up and we can begin the planning process.
>>
Re: move to git.
Posted by Pierre Smits <pi...@gmail.com>.
Quoting:
We are also prepared to be assertive regarding this situation. If the
project
does not move to GIT then Brainfood is willing to participate in a
consortium of
organizations that will peer with each other to share updates to the master
branch for their local OFBiz repository. Such an arrangement will,
effectively,
result in a distributed master repository image.
Thanks Ean for the position of *Brainfood* in this position. It comes
across as 'Do it our way, or else'. You are free to make such statements
and when followed through there will be consequences. For all participating
in this project. One I can see standing out clearly is: no more
participation in/contribution from the employees of Brainfood and from the
other companies in that consortium back into the project.
If that is going to happen, I will say: 'I thank you for all the
contributions you did to the project'. And I will check in my sentiments at
the door. I do hope that if you do you also resign totally from this
project.
I rather have the community comes to its decision based on sound/valid
arguments, not (veiled) threats.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler <ea...@brainfood.com> wrote:
> ----- Original Message -----
> > From: "Jacques Le Roux" <ja...@les7arts.com>
> > Subject: Re: move to git.
>
> > Like Adrian and mostly for the same reasons, I don't believe we need Git.
> >
> > But there is one other major reason which has already been discussed in
> the
> > other common ASF MLs. As Taher exulted, it's possible to create local
> > branches. So people are able to do a lot of work alone without
> exchanging before
> > committing or submitting. It will certainly not help to have this
> > possibility.
>
> I disagree. It is useful in many situations for OFBiz developers to create
> a
> local repository that is not globally shared. Some customers may even
> require
> such a situation for security or legal reasons.
>
> > Remember our recent discussion on the lack or core commits reviews.
> > With Git you end with commits bursts or big patches and it's then
> > hard to review and too late to share ideas.
> >
> > So unlike Adrian, I'm even strongly against it. I will not hesitate to
> use a -1
> > if necessary!
>
> We are also prepared to be assertive regarding this situation. If the
> project
> does not move to GIT then Brainfood is willing to participate in a
> consortium of
> organizations that will peer with each other to share updates to the master
> branch for their local OFBiz repository. Such an arrangement will,
> effectively,
> result in a distributed master repository image.
>
> If anyone else is interested in such an arrangement please feel free to
> speak
> up and we can begin the planning process.
>
Re: move to git.
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 21/04/2015 6:55 AM, Jacopo Cappellato wrote:
> On Apr 21, 2015, at 11:23 AM, Jacques Le Roux <ja...@les7arts.com> wrote:
>
>>> Switching the main repo to Git does not add anything to the project itself. As I said before, Subversion handles our simple needs just fine. If Jacopo said something like, "Managing our releases is impossible with Subversion, we really need to switch to Git" - then we wouldn't be having this discussion, it would just happen because the need for the switch is obvious.
>>>
>>> But Jacopo is not saying that, and we don't have a problem using Subversion to manage the project.
>> I don't remember Jacopo proposed to move to Git, it was Hans, then Taher, Adam and Ean seconded. I guess Taher, AntWeb and Brainfood are using Git and they would like to see OFBiz using it as well.
> In fact I didn't express my opinion or preference.
> At Hotwax we use Git for all our projects and we are happy with it. But this doesn't mean that svn is bad or old or not a good tool for OFBiz.
> In fact, as I mentioned to Hans at ApacheCon, before discussing "svn vs git" as mere tools, it would be more interesting and useful to review/discuss the contribution/commit workflows that these tools can enable and see if there is a room for a better workflow for the project.
>
> Jacopo
I think that this is a very good summary of the issue.
It appears to me that there is a fundamental shift of philosophy that
"Move to git" is discussing rather than a tool switch.
With git it is much easier to develop parallel "products".
I could chose to follow Jacopo's public repo or Ean's rather than the
"official" OFBiz repo if I felt that they were doing things that I liked
that were not being committed to the OFBiz repo.
I could take changes from more than one repo if I felt that I could
handle the integration workload and maintain a blended product.
I could make changes and request that any other repo that wanted to have
them, take them but I have no guarantee that Jacopo, Ean or OFBiz would
accept them.
I could use the Apache JIRA to document my patch or not.
Clearly a JIRA issue would get more discussion and might cause me to
revise my "contribution" or make it more likely to be accepted if the
concensus is that it is a "good thing".
I could create my own issue tracking system and invite others to look
there for my ideas.
Each one of the versions could have its own release schedule.
This is substantially different that the current situation and I think
that Jacopo's suggested course of action of looking at the proposal as a
question of workflow is a good idea.
Underlying this discussion, there is a dissatisfaction with the workflow
expressed by people who are not committers (in general).
There are a lot of private forks of OFBiz already but most of the ones
that show up here are based on the OFBiz trunk and are produced by
committers who contribute back some of their local changes.
In some ways, moving to a more distributed system, does help make OFBiz
stronger. The keepers of the OFBiz repo have control as they do now
about what changes get incorporated into the OFBiz "trunk". Others can
continue to use the contributions to the trunk but are still able to use
"improvements" from other repos that have been rejected by the community.
There are licensing issues that I would have to deal with as a
maintainer of a private repo if I start to include work from non-Apache
repos since I can not be quite so sure that the contributions to the
private repo have been released to me under an Apache license.
I am not advocating a shift to git, just trying to support Jacopo's
suggestion of looking at workflow first with a slight addition of
extending the discussion to project management philosophy since that
seems to be a key motivation underlying the suggestion to move.
Ron
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: move to git.
Posted by Pierre Smits <pi...@gmail.com>.
@Adrian: I didn't miss your point! Opted not to respond, as I saw nothing
wrong with/in the assertion/point you posted.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Tue, Apr 21, 2015 at 12:59 PM, Adrian Crum <
adrian.crum@sandglass-software.com> wrote:
> Everyone is missing the point I am trying to make.
>
> I said, "***IF*** Jacopo said something like..."
>
> As the OFBiz RM, ***IF*** Jacopo said he couldn't use Subversion to manage
> the OFBiz project, then the need to switch to something else would be
> obvious.
>
> I hope that clarifies my true meaning.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 4/21/2015 11:55 AM, Jacopo Cappellato wrote:
>
>> On Apr 21, 2015, at 11:23 AM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>> Switching the main repo to Git does not add anything to the project
>>>> itself. As I said before, Subversion handles our simple needs just fine. If
>>>> Jacopo said something like, "Managing our releases is impossible with
>>>> Subversion, we really need to switch to Git" - then we wouldn't be having
>>>> this discussion, it would just happen because the need for the switch is
>>>> obvious.
>>>>
>>>> But Jacopo is not saying that, and we don't have a problem using
>>>> Subversion to manage the project.
>>>>
>>>
>>> I don't remember Jacopo proposed to move to Git, it was Hans, then
>>> Taher, Adam and Ean seconded. I guess Taher, AntWeb and Brainfood are using
>>> Git and they would like to see OFBiz using it as well.
>>>
>>
>> In fact I didn't express my opinion or preference.
>> At Hotwax we use Git for all our projects and we are happy with it. But
>> this doesn't mean that svn is bad or old or not a good tool for OFBiz.
>> In fact, as I mentioned to Hans at ApacheCon, before discussing "svn vs
>> git" as mere tools, it would be more interesting and useful to
>> review/discuss the contribution/commit workflows that these tools can
>> enable and see if there is a room for a better workflow for the project.
>>
>> Jacopo
>>
>>
Re: move to git.
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
I agree it is important to consider the current situation and the possible workflows before discussing the tools.
Currently we do the following:
* trunk is where all development happens
* most of the commits to trunk are done following the Commit Then Review workflow; sometimes, for more complex or controversial changes, we follow the Review Then Commit workflow; sometimes we create experimental branches that are then merged into the trunk
* release branches are stabilization branches: snapshots of the trunk at a given point of time, then (mostly) only backporting of bugs are done
* a new release branch is approximately created every year
* release branches are actively maintained for 3-4 years
When we discuss version control systems (e.g. svn, git) for OFBiz, we should also consider the following questions:
* is the current workflow the best for OFBiz and its ecosystem?
* if we want to change the workflow, which one we would be the best? For example: Forking Workflow, Gitflow Workflow, Feature Branch Workflow etc...
* is the new workflow compatible with the ASF guidelines and rules?
* what is the best tool for the new workflow? e.g. git, svn
Regards,
Jacopo
On Apr 21, 2015, at 2:11 PM, Pierre Smits <pi...@gmail.com> wrote:
> As far as I can see it, this whole discussion regarding GIT vs SVN (move to
> GIT), is dependent on and blocked by the perceptions of (and viewpoints on)
> the (in)clarity surrounding how we (as the contributing community) deal
> with code-changing contributions (CTR vs RTC/patches vs dumps).
>
> If we don’t deal with that first, I see blockers on the road forward every
> time we reiterate this GIT vs SVN discussion. Like it there were before and
> are now.
>
> It seems we (all) need a realignment and/or re-acceptance of our G & C (of
> the GRC) in that area first.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Tue, Apr 21, 2015 at 1:22 PM, Jacopo Cappellato <
> jacopo.cappellato@hotwaxsystems.com> wrote:
>
>> On Apr 21, 2015, at 12:59 PM, Adrian Crum <
>> adrian.crum@sandglass-software.com> wrote:
>>
>>> Everyone is missing the point I am trying to make.
>>>
>>> I said, "***IF*** Jacopo said something like..."
>>>
>>> As the OFBiz RM, ***IF*** Jacopo said he couldn't use Subversion to
>> manage the OFBiz project, then the need to switch to something else would
>> be obvious.
>>>
>>> I hope that clarifies my true meaning.
>>>
>>> Adrian Crum
>>
>> It was clear to me since your first message but I have replied to Jacques
>> as I was starting to feel dragged (or, in the context of git, I should say
>> "pulled") into the mix :-)
>>
>> Jacopo
>>
>>
Re: move to git.
Posted by Pierre Smits <pi...@gmail.com>.
As far as I can see it, this whole discussion regarding GIT vs SVN (move to
GIT), is dependent on and blocked by the perceptions of (and viewpoints on)
the (in)clarity surrounding how we (as the contributing community) deal
with code-changing contributions (CTR vs RTC/patches vs dumps).
If we don’t deal with that first, I see blockers on the road forward every
time we reiterate this GIT vs SVN discussion. Like it there were before and
are now.
It seems we (all) need a realignment and/or re-acceptance of our G & C (of
the GRC) in that area first.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Tue, Apr 21, 2015 at 1:22 PM, Jacopo Cappellato <
jacopo.cappellato@hotwaxsystems.com> wrote:
> On Apr 21, 2015, at 12:59 PM, Adrian Crum <
> adrian.crum@sandglass-software.com> wrote:
>
> > Everyone is missing the point I am trying to make.
> >
> > I said, "***IF*** Jacopo said something like..."
> >
> > As the OFBiz RM, ***IF*** Jacopo said he couldn't use Subversion to
> manage the OFBiz project, then the need to switch to something else would
> be obvious.
> >
> > I hope that clarifies my true meaning.
> >
> > Adrian Crum
>
> It was clear to me since your first message but I have replied to Jacques
> as I was starting to feel dragged (or, in the context of git, I should say
> "pulled") into the mix :-)
>
> Jacopo
>
>
Re: move to git.
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
On Apr 21, 2015, at 12:59 PM, Adrian Crum <ad...@sandglass-software.com> wrote:
> Everyone is missing the point I am trying to make.
>
> I said, "***IF*** Jacopo said something like..."
>
> As the OFBiz RM, ***IF*** Jacopo said he couldn't use Subversion to manage the OFBiz project, then the need to switch to something else would be obvious.
>
> I hope that clarifies my true meaning.
>
> Adrian Crum
It was clear to me since your first message but I have replied to Jacques as I was starting to feel dragged (or, in the context of git, I should say "pulled") into the mix :-)
Jacopo
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Thanks for clarification Adrian,
I did not think about the Release Manager role
Jacques
Le 21/04/2015 12:59, Adrian Crum a écrit :
> Everyone is missing the point I am trying to make.
>
> I said, "***IF*** Jacopo said something like..."
>
> As the OFBiz RM, ***IF*** Jacopo said he couldn't use Subversion to manage the OFBiz project, then the need to switch to something else would be
> obvious.
>
> I hope that clarifies my true meaning.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 4/21/2015 11:55 AM, Jacopo Cappellato wrote:
>> On Apr 21, 2015, at 11:23 AM, Jacques Le Roux <ja...@les7arts.com> wrote:
>>
>>>> Switching the main repo to Git does not add anything to the project itself. As I said before, Subversion handles our simple needs just fine. If
>>>> Jacopo said something like, "Managing our releases is impossible with Subversion, we really need to switch to Git" - then we wouldn't be having
>>>> this discussion, it would just happen because the need for the switch is obvious.
>>>>
>>>> But Jacopo is not saying that, and we don't have a problem using Subversion to manage the project.
>>>
>>> I don't remember Jacopo proposed to move to Git, it was Hans, then Taher, Adam and Ean seconded. I guess Taher, AntWeb and Brainfood are using Git
>>> and they would like to see OFBiz using it as well.
>>
>> In fact I didn't express my opinion or preference.
>> At Hotwax we use Git for all our projects and we are happy with it. But this doesn't mean that svn is bad or old or not a good tool for OFBiz.
>> In fact, as I mentioned to Hans at ApacheCon, before discussing "svn vs git" as mere tools, it would be more interesting and useful to
>> review/discuss the contribution/commit workflows that these tools can enable and see if there is a room for a better workflow for the project.
>>
>> Jacopo
>>
>
Re: move to git.
Posted by Adrian Crum <ad...@sandglass-software.com>.
Everyone is missing the point I am trying to make.
I said, "***IF*** Jacopo said something like..."
As the OFBiz RM, ***IF*** Jacopo said he couldn't use Subversion to
manage the OFBiz project, then the need to switch to something else
would be obvious.
I hope that clarifies my true meaning.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 4/21/2015 11:55 AM, Jacopo Cappellato wrote:
> On Apr 21, 2015, at 11:23 AM, Jacques Le Roux <ja...@les7arts.com> wrote:
>
>>> Switching the main repo to Git does not add anything to the project itself. As I said before, Subversion handles our simple needs just fine. If Jacopo said something like, "Managing our releases is impossible with Subversion, we really need to switch to Git" - then we wouldn't be having this discussion, it would just happen because the need for the switch is obvious.
>>>
>>> But Jacopo is not saying that, and we don't have a problem using Subversion to manage the project.
>>
>> I don't remember Jacopo proposed to move to Git, it was Hans, then Taher, Adam and Ean seconded. I guess Taher, AntWeb and Brainfood are using Git and they would like to see OFBiz using it as well.
>
> In fact I didn't express my opinion or preference.
> At Hotwax we use Git for all our projects and we are happy with it. But this doesn't mean that svn is bad or old or not a good tool for OFBiz.
> In fact, as I mentioned to Hans at ApacheCon, before discussing "svn vs git" as mere tools, it would be more interesting and useful to review/discuss the contribution/commit workflows that these tools can enable and see if there is a room for a better workflow for the project.
>
> Jacopo
>
Re: move to git.
Posted by Jacopo Cappellato <ja...@hotwaxsystems.com>.
On Apr 21, 2015, at 11:23 AM, Jacques Le Roux <ja...@les7arts.com> wrote:
>> Switching the main repo to Git does not add anything to the project itself. As I said before, Subversion handles our simple needs just fine. If Jacopo said something like, "Managing our releases is impossible with Subversion, we really need to switch to Git" - then we wouldn't be having this discussion, it would just happen because the need for the switch is obvious.
>>
>> But Jacopo is not saying that, and we don't have a problem using Subversion to manage the project.
>
> I don't remember Jacopo proposed to move to Git, it was Hans, then Taher, Adam and Ean seconded. I guess Taher, AntWeb and Brainfood are using Git and they would like to see OFBiz using it as well.
In fact I didn't express my opinion or preference.
At Hotwax we use Git for all our projects and we are happy with it. But this doesn't mean that svn is bad or old or not a good tool for OFBiz.
In fact, as I mentioned to Hans at ApacheCon, before discussing "svn vs git" as mere tools, it would be more interesting and useful to review/discuss the contribution/commit workflows that these tools can enable and see if there is a room for a better workflow for the project.
Jacopo
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 21/04/2015 11:08, Adrian Crum a écrit :
> Taher,
>
> Nothing in your reply is new or different. People have been doing that for years with Subversion. Git did not invent local repositories.
>
> Connecting a local Git repository to the OFBiz Subversion repository is a problem for some, that is why we are having this discussion.
>
> So far, two proposals have been made:
>
> 1. Switch the OFBiz project to Git.
> 2. Host a separate Git repo that is a copy of the OFBiz Subversion repo.
>
> How those proposals affect OFBiz developers:
>
> 1. Subversion users must switch to Git clients and learn Git.
> 2. Git users can access the project through the Git repo, Subversion users continue using Subversion with the main OFBiz repo.
>
> Switching the main repo to Git does not add anything to the project itself. As I said before, Subversion handles our simple needs just fine. If
> Jacopo said something like, "Managing our releases is impossible with Subversion, we really need to switch to Git" - then we wouldn't be having this
> discussion, it would just happen because the need for the switch is obvious.
>
> But Jacopo is not saying that, and we don't have a problem using Subversion to manage the project.
I don't remember Jacopo proposed to move to Git, it was Hans, then Taher, Adam and Ean seconded. I guess Taher, AntWeb and Brainfood are using Git and
they would like to see OFBiz using it as well.
I have been using a Git repo for a custom project. I simply put the OFBiz .svn in the Git working copy and repo et voilà.
I had the best of both world, I could easily backport my contributions in OFBiz. It's also very convenient for other reasons.
I must admit it's not available for non committers who have to create patches, nothing new..
Jacques
>
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 4/21/2015 9:19 AM, Taher Alkhateeb wrote:
>> Hi Jacques and all,
>>
>> I think that sharing more than anything is a reason why git has an
>> advantage. The distributed system means that every developer is a
>> repository and therefore you can have endless chains of code propagation up
>> to a committer. Just imagine a scenario like the following
>>
>> - A team is composed of people working on a major task
>> - Two of the members (A and B) have their own sub-teams
>> - There is exchange of code between the sub-teams, the major team and the
>> project committer. Furthermore, the sub-teams need to pull updated data
>> from the main repository of the project.
>>
>> So you have two integrators at the sub-team level and one integrator at the
>> top team level plus a project committer. Sometimes, I want to pull code
>> from the sub-team. Sometimes I want to pull code from the _other_ team.
>> Then maybe I want to _merge_ work from both teams and run all tests. Then I
>> want to clean the commit log with "git rebase" to cleanup the history into
>> major commits to submit to the project committer. Now the project owner
>> does not know / trust me but he knows / trusts you. And you in turn trust
>> me so you can accept my commits.
>>
>> I cannot imagine how to implement the above without a distributed source
>> code management system. Furthermore, it's important to note that ofbiz is
>> not a closed proprietary project with a sacred repository hidden in the
>> vault of some company. You _need_ contributions from others and you need to
>> make it very easy and accessible. You need to have the ability for people
>> to form teams and sub-teams to support you and your project by
>> collaborating with each other without needing a committer. This is one of
>> the main reasons for the massive success of the Linux Kernel where each of
>> Linus Torvald's lieutenants is a committer for a sub-system with his/her
>> own people they trust and work closely with. Some of this stuff is briefly
>> shown in here http://www.git-scm.com/about/distributed
>>
>> I hope what I wrote is resonating with you and you're willing to give this
>> idea a chance
>>
>> Taher Alkhateeb
>>
>> On Tue, Apr 21, 2015 at 10:23 AM, Jacques Le Roux <
>> jacques.le.roux@les7arts.com> wrote:
>>
>>> Le 21/04/2015 02:08, Ean Schuessler a écrit :
>>>
>>>> ----- Original Message -----
>>>>
>>>>> From: "Jacques Le Roux" <ja...@les7arts.com>
>>>>> Subject: Re: move to git.
>>>>> Like Adrian and mostly for the same reasons, I don't believe we need Git.
>>>>>
>>>>> But there is one other major reason which has already been discussed in
>>>>> the
>>>>> other common ASF MLs. As Taher exulted, it's possible to create local
>>>>> branches. So people are able to do a lot of work alone without
>>>>> exchanging before
>>>>> committing or submitting. It will certainly not help to have this
>>>>> possibility.
>>>>>
>>>> I disagree. It is useful in many situations for OFBiz developers to
>>>> create a
>>>> local repository that is not globally shared.
>>>>
>>>
>>> What about https://github.com/apache/ofbiz ?
>>>
>>> Some customers may even require
>>>> such a situation for security or legal reasons.
>>>>
>>>
>>> People can do what they want with OFBiz code on their side, sharing with
>>> the community is something else (and often harder)
>>>
>>> Jacques
>>>
>>>
>>>> Remember our recent discussion on the lack or core commits reviews.
>>>>> With Git you end with commits bursts or big patches and it's then
>>>>> hard to review and too late to share ideas.
>>>>>
>>>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>>>>> use a -1
>>>>> if necessary!
>>>>>
>>>> We are also prepared to be assertive regarding this situation. If the
>>>> project
>>>> does not move to GIT then Brainfood is willing to participate in a
>>>> consortium of
>>>> organizations that will peer with each other to share updates to the
>>>> master
>>>> branch for their local OFBiz repository. Such an arrangement will,
>>>> effectively,
>>>> result in a distributed master repository image.
>>>>
>>>> If anyone else is interested in such an arrangement please feel free to
>>>> speak
>>>> up and we can begin the planning process.
>>>>
>>>>
>>
>
Re: move to git.
Posted by Adrian Crum <ad...@sandglass-software.com>.
Taher,
Nothing in your reply is new or different. People have been doing that
for years with Subversion. Git did not invent local repositories.
Connecting a local Git repository to the OFBiz Subversion repository is
a problem for some, that is why we are having this discussion.
So far, two proposals have been made:
1. Switch the OFBiz project to Git.
2. Host a separate Git repo that is a copy of the OFBiz Subversion repo.
How those proposals affect OFBiz developers:
1. Subversion users must switch to Git clients and learn Git.
2. Git users can access the project through the Git repo, Subversion
users continue using Subversion with the main OFBiz repo.
Switching the main repo to Git does not add anything to the project
itself. As I said before, Subversion handles our simple needs just fine.
If Jacopo said something like, "Managing our releases is impossible with
Subversion, we really need to switch to Git" - then we wouldn't be
having this discussion, it would just happen because the need for the
switch is obvious.
But Jacopo is not saying that, and we don't have a problem using
Subversion to manage the project.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 4/21/2015 9:19 AM, Taher Alkhateeb wrote:
> Hi Jacques and all,
>
> I think that sharing more than anything is a reason why git has an
> advantage. The distributed system means that every developer is a
> repository and therefore you can have endless chains of code propagation up
> to a committer. Just imagine a scenario like the following
>
> - A team is composed of people working on a major task
> - Two of the members (A and B) have their own sub-teams
> - There is exchange of code between the sub-teams, the major team and the
> project committer. Furthermore, the sub-teams need to pull updated data
> from the main repository of the project.
>
> So you have two integrators at the sub-team level and one integrator at the
> top team level plus a project committer. Sometimes, I want to pull code
> from the sub-team. Sometimes I want to pull code from the _other_ team.
> Then maybe I want to _merge_ work from both teams and run all tests. Then I
> want to clean the commit log with "git rebase" to cleanup the history into
> major commits to submit to the project committer. Now the project owner
> does not know / trust me but he knows / trusts you. And you in turn trust
> me so you can accept my commits.
>
> I cannot imagine how to implement the above without a distributed source
> code management system. Furthermore, it's important to note that ofbiz is
> not a closed proprietary project with a sacred repository hidden in the
> vault of some company. You _need_ contributions from others and you need to
> make it very easy and accessible. You need to have the ability for people
> to form teams and sub-teams to support you and your project by
> collaborating with each other without needing a committer. This is one of
> the main reasons for the massive success of the Linux Kernel where each of
> Linus Torvald's lieutenants is a committer for a sub-system with his/her
> own people they trust and work closely with. Some of this stuff is briefly
> shown in here http://www.git-scm.com/about/distributed
>
> I hope what I wrote is resonating with you and you're willing to give this
> idea a chance
>
> Taher Alkhateeb
>
> On Tue, Apr 21, 2015 at 10:23 AM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Le 21/04/2015 02:08, Ean Schuessler a écrit :
>>
>>> ----- Original Message -----
>>>
>>>> From: "Jacques Le Roux" <ja...@les7arts.com>
>>>> Subject: Re: move to git.
>>>> Like Adrian and mostly for the same reasons, I don't believe we need Git.
>>>>
>>>> But there is one other major reason which has already been discussed in
>>>> the
>>>> other common ASF MLs. As Taher exulted, it's possible to create local
>>>> branches. So people are able to do a lot of work alone without
>>>> exchanging before
>>>> committing or submitting. It will certainly not help to have this
>>>> possibility.
>>>>
>>> I disagree. It is useful in many situations for OFBiz developers to
>>> create a
>>> local repository that is not globally shared.
>>>
>>
>> What about https://github.com/apache/ofbiz ?
>>
>> Some customers may even require
>>> such a situation for security or legal reasons.
>>>
>>
>> People can do what they want with OFBiz code on their side, sharing with
>> the community is something else (and often harder)
>>
>> Jacques
>>
>>
>>> Remember our recent discussion on the lack or core commits reviews.
>>>> With Git you end with commits bursts or big patches and it's then
>>>> hard to review and too late to share ideas.
>>>>
>>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>>>> use a -1
>>>> if necessary!
>>>>
>>> We are also prepared to be assertive regarding this situation. If the
>>> project
>>> does not move to GIT then Brainfood is willing to participate in a
>>> consortium of
>>> organizations that will peer with each other to share updates to the
>>> master
>>> branch for their local OFBiz repository. Such an arrangement will,
>>> effectively,
>>> result in a distributed master repository image.
>>>
>>> If anyone else is interested in such an arrangement please feel free to
>>> speak
>>> up and we can begin the planning process.
>>>
>>>
>
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 21/04/2015 10:19, Taher Alkhateeb a écrit :
> Hi Jacques and all,
>
> I think that sharing more than anything is a reason why git has an
> advantage. The distributed system means that every developer is a
> repository and therefore you can have endless chains of code propagation up
> to a committer. Just imagine a scenario like the following
>
> - A team is composed of people working on a major task
> - Two of the members (A and B) have their own sub-teams
> - There is exchange of code between the sub-teams, the major team and the
> project committer. Furthermore, the sub-teams need to pull updated data
> from the main repository of the project.
>
> So you have two integrators at the sub-team level and one integrator at the
> top team level plus a project committer. Sometimes, I want to pull code
> from the sub-team. Sometimes I want to pull code from the _other_ team.
> Then maybe I want to _merge_ work from both teams and run all tests. Then I
> want to clean the commit log with "git rebase" to cleanup the history into
> major commits to submit to the project committer. Now the project owner
> does not know / trust me but he knows / trusts you. And you in turn trust
> me so you can accept my commits.
>
> I cannot imagine how to implement the above without a distributed source
> code management system. Furthermore, it's important to note that ofbiz is
> not a closed proprietary project with a sacred repository hidden in the
> vault of some company. You _need_ contributions from others and you need to
> make it very easy and accessible. You need to have the ability for people
> to form teams and sub-teams to support you and your project by
> collaborating with each other without needing a committer. This is one of
> the main reasons for the massive success of the Linux Kernel where each of
> Linus Torvald's lieutenants is a committer for a sub-system with his/her
> own people they trust and work closely with. Some of this stuff is briefly
> shown in here http://www.git-scm.com/about/distributed
>
> I hope what I wrote is resonating with you and you're willing to give this
> idea a chance
OK, you kind of answered to my questions to Adam, I need to re-read carefully...
Jacques
>
> Taher Alkhateeb
>
> On Tue, Apr 21, 2015 at 10:23 AM, Jacques Le Roux <
> jacques.le.roux@les7arts.com> wrote:
>
>> Le 21/04/2015 02:08, Ean Schuessler a écrit :
>>
>>> ----- Original Message -----
>>>
>>>> From: "Jacques Le Roux" <ja...@les7arts.com>
>>>> Subject: Re: move to git.
>>>> Like Adrian and mostly for the same reasons, I don't believe we need Git.
>>>>
>>>> But there is one other major reason which has already been discussed in
>>>> the
>>>> other common ASF MLs. As Taher exulted, it's possible to create local
>>>> branches. So people are able to do a lot of work alone without
>>>> exchanging before
>>>> committing or submitting. It will certainly not help to have this
>>>> possibility.
>>>>
>>> I disagree. It is useful in many situations for OFBiz developers to
>>> create a
>>> local repository that is not globally shared.
>>>
>> What about https://github.com/apache/ofbiz ?
>>
>> Some customers may even require
>>> such a situation for security or legal reasons.
>>>
>> People can do what they want with OFBiz code on their side, sharing with
>> the community is something else (and often harder)
>>
>> Jacques
>>
>>
>>> Remember our recent discussion on the lack or core commits reviews.
>>>> With Git you end with commits bursts or big patches and it's then
>>>> hard to review and too late to share ideas.
>>>>
>>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>>>> use a -1
>>>> if necessary!
>>>>
>>> We are also prepared to be assertive regarding this situation. If the
>>> project
>>> does not move to GIT then Brainfood is willing to participate in a
>>> consortium of
>>> organizations that will peer with each other to share updates to the
>>> master
>>> branch for their local OFBiz repository. Such an arrangement will,
>>> effectively,
>>> result in a distributed master repository image.
>>>
>>> If anyone else is interested in such an arrangement please feel free to
>>> speak
>>> up and we can begin the planning process.
>>>
>>>
Re: move to git.
Posted by Taher Alkhateeb <sl...@gmail.com>.
Hi Jacques and all,
I think that sharing more than anything is a reason why git has an
advantage. The distributed system means that every developer is a
repository and therefore you can have endless chains of code propagation up
to a committer. Just imagine a scenario like the following
- A team is composed of people working on a major task
- Two of the members (A and B) have their own sub-teams
- There is exchange of code between the sub-teams, the major team and the
project committer. Furthermore, the sub-teams need to pull updated data
from the main repository of the project.
So you have two integrators at the sub-team level and one integrator at the
top team level plus a project committer. Sometimes, I want to pull code
from the sub-team. Sometimes I want to pull code from the _other_ team.
Then maybe I want to _merge_ work from both teams and run all tests. Then I
want to clean the commit log with "git rebase" to cleanup the history into
major commits to submit to the project committer. Now the project owner
does not know / trust me but he knows / trusts you. And you in turn trust
me so you can accept my commits.
I cannot imagine how to implement the above without a distributed source
code management system. Furthermore, it's important to note that ofbiz is
not a closed proprietary project with a sacred repository hidden in the
vault of some company. You _need_ contributions from others and you need to
make it very easy and accessible. You need to have the ability for people
to form teams and sub-teams to support you and your project by
collaborating with each other without needing a committer. This is one of
the main reasons for the massive success of the Linux Kernel where each of
Linus Torvald's lieutenants is a committer for a sub-system with his/her
own people they trust and work closely with. Some of this stuff is briefly
shown in here http://www.git-scm.com/about/distributed
I hope what I wrote is resonating with you and you're willing to give this
idea a chance
Taher Alkhateeb
On Tue, Apr 21, 2015 at 10:23 AM, Jacques Le Roux <
jacques.le.roux@les7arts.com> wrote:
> Le 21/04/2015 02:08, Ean Schuessler a écrit :
>
>> ----- Original Message -----
>>
>>> From: "Jacques Le Roux" <ja...@les7arts.com>
>>> Subject: Re: move to git.
>>> Like Adrian and mostly for the same reasons, I don't believe we need Git.
>>>
>>> But there is one other major reason which has already been discussed in
>>> the
>>> other common ASF MLs. As Taher exulted, it's possible to create local
>>> branches. So people are able to do a lot of work alone without
>>> exchanging before
>>> committing or submitting. It will certainly not help to have this
>>> possibility.
>>>
>> I disagree. It is useful in many situations for OFBiz developers to
>> create a
>> local repository that is not globally shared.
>>
>
> What about https://github.com/apache/ofbiz ?
>
> Some customers may even require
>> such a situation for security or legal reasons.
>>
>
> People can do what they want with OFBiz code on their side, sharing with
> the community is something else (and often harder)
>
> Jacques
>
>
>> Remember our recent discussion on the lack or core commits reviews.
>>> With Git you end with commits bursts or big patches and it's then
>>> hard to review and too late to share ideas.
>>>
>>> So unlike Adrian, I'm even strongly against it. I will not hesitate to
>>> use a -1
>>> if necessary!
>>>
>> We are also prepared to be assertive regarding this situation. If the
>> project
>> does not move to GIT then Brainfood is willing to participate in a
>> consortium of
>> organizations that will peer with each other to share updates to the
>> master
>> branch for their local OFBiz repository. Such an arrangement will,
>> effectively,
>> result in a distributed master repository image.
>>
>> If anyone else is interested in such an arrangement please feel free to
>> speak
>> up and we can begin the planning process.
>>
>>
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Le 21/04/2015 02:08, Ean Schuessler a écrit :
> ----- Original Message -----
>> From: "Jacques Le Roux" <ja...@les7arts.com>
>> Subject: Re: move to git.
>> Like Adrian and mostly for the same reasons, I don't believe we need Git.
>>
>> But there is one other major reason which has already been discussed in the
>> other common ASF MLs. As Taher exulted, it's possible to create local
>> branches. So people are able to do a lot of work alone without exchanging before
>> committing or submitting. It will certainly not help to have this
>> possibility.
> I disagree. It is useful in many situations for OFBiz developers to create a
> local repository that is not globally shared.
What about https://github.com/apache/ofbiz ?
> Some customers may even require
> such a situation for security or legal reasons.
People can do what they want with OFBiz code on their side, sharing with the community is something else (and often harder)
Jacques
>
>> Remember our recent discussion on the lack or core commits reviews.
>> With Git you end with commits bursts or big patches and it's then
>> hard to review and too late to share ideas.
>>
>> So unlike Adrian, I'm even strongly against it. I will not hesitate to use a -1
>> if necessary!
> We are also prepared to be assertive regarding this situation. If the project
> does not move to GIT then Brainfood is willing to participate in a consortium of
> organizations that will peer with each other to share updates to the master
> branch for their local OFBiz repository. Such an arrangement will, effectively,
> result in a distributed master repository image.
>
> If anyone else is interested in such an arrangement please feel free to speak
> up and we can begin the planning process.
>
Re: move to git.
Posted by Ean Schuessler <ea...@brainfood.com>.
----- Original Message -----
> From: "Jacques Le Roux" <ja...@les7arts.com>
> Subject: Re: move to git.
> Like Adrian and mostly for the same reasons, I don't believe we need Git.
>
> But there is one other major reason which has already been discussed in the
> other common ASF MLs. As Taher exulted, it's possible to create local
> branches. So people are able to do a lot of work alone without exchanging before
> committing or submitting. It will certainly not help to have this
> possibility.
I disagree. It is useful in many situations for OFBiz developers to create a
local repository that is not globally shared. Some customers may even require
such a situation for security or legal reasons.
> Remember our recent discussion on the lack or core commits reviews.
> With Git you end with commits bursts or big patches and it's then
> hard to review and too late to share ideas.
>
> So unlike Adrian, I'm even strongly against it. I will not hesitate to use a -1
> if necessary!
We are also prepared to be assertive regarding this situation. If the project
does not move to GIT then Brainfood is willing to participate in a consortium of
organizations that will peer with each other to share updates to the master
branch for their local OFBiz repository. Such an arrangement will, effectively,
result in a distributed master repository image.
If anyone else is interested in such an arrangement please feel free to speak
up and we can begin the planning process.
Re: move to git.
Posted by Jacques Le Roux <ja...@les7arts.com>.
Like Adrian and mostly for the same reasons, I don't believe we need Git.
But there is one other major reason which has already been discussed in the other common ASF MLs. As Taher exulted, it's possible to create local
branches. So people are able to do a lot of work alone without exchanging before committing or submitting. It will certainly not help to have this
possibility. Remember our recent discussion on the lack or core commits reviews. With Git you end with commits bursts or big patches and it's then
hard to review and too late to share ideas.
So unlike Adrian, I'm even strongly against it. I will not hesitate to use a -1 if necessary!
Jacques
Le 20/04/2015 09:53, Adrian Crum a écrit :
> I don't agree that "all major contributors are using git."
>
> Personally, I find Git to be an overly complicated solution to a simple problem. It frequently does bizarre things that no one understands, and you
> are left with things being mysteriously reverted for unknown reasons.
>
> This isn't a -1 vote though. I'm just making it clear that I will be dragged kicking and screaming into using it.
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
> On 4/20/2015 5:38 AM, Hans Bakker wrote:
>> As discussed at apachecon in Austin, i propose to switch from svn to git
>> for the ofbiz repository. The main reason being that all major
>> contributors are using git and contributions are cumbersome, further,
>> git allows for better branching and merging.
>>
>> Regards,
>> Hans
>
Re: move to git.
Posted by Adrian Crum <ad...@sandglass-software.com>.
I don't agree that "all major contributors are using git."
Personally, I find Git to be an overly complicated solution to a simple
problem. It frequently does bizarre things that no one understands, and
you are left with things being mysteriously reverted for unknown reasons.
This isn't a -1 vote though. I'm just making it clear that I will be
dragged kicking and screaming into using it.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 4/20/2015 5:38 AM, Hans Bakker wrote:
> As discussed at apachecon in Austin, i propose to switch from svn to git
> for the ofbiz repository. The main reason being that all major
> contributors are using git and contributions are cumbersome, further,
> git allows for better branching and merging.
>
> Regards,
> Hans