subject:"move to git."


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 mailingl...@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.bak...@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.

On May 6, 2015, at 3:34 AM, Hans Bakker h.bak...@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.

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


On May 6, 2015, at 8:56 AM, Hans Bakker mailingl...@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 mailingl...@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 mailingl...@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.bak...@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.

On May 6, 2015, at 8:46 AM, Hans Bakker mailingl...@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 mailingl...@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.bak...@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.

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 mailingl...@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 mailingl...@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.bak...@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.

On May 6, 2015, at 8:43 AM, Taher Alkhateeb slidingfilame...@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.cappell...@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 mailingl...@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.bak...@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.


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 mailingl...@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 mailingl...@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 mailingl...@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.bak...@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.

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

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 mailingl...@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.bak...@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.

2015-05-06 Thread Pierre Smits

Consensus is always needed.

Best regards,

Pierre

Op woensdag 6 mei 2015 heeft Hans Bakker mailingl...@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 mailingl...@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 mailingl...@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 
 mailingl...@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.bak...@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.

On May 6, 2015, at 9:10 AM, Hans Bakker mailingl...@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.

On May 6, 2015, at 9:54 AM, Hans Bakker mailingl...@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.

2015-05-06 Thread Taher Alkhateeb

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.cappell...@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 mailingl...@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.bak...@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.

2015-05-06 Thread Christian Geisert

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

2015-05-05 Thread Jacopo Cappellato

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

2015-05-05 Thread Adrian Crum


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

2015-05-05 Thread Hans Bakker


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

2015-05-05 Thread Adam Heath

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

2015-05-05 Thread Julien NICOLAS


+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: Vote: move to git.

2015-05-05 Thread Nicolas Malin

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

2015-05-05 Thread Gil portenseigne


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

2015-05-05 Thread Christian Geisert

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.

2015-05-05 Thread Michael Brohl


+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







smime.p7s
Description: S/MIME Cryptographic Signature

Re: Vote: move to git.

2015-05-05 Thread Martin Becker



smime.p7m
Description: S/MIME encrypted message

Re: Vote: move to git.

2015-05-05 Thread Martin Becker

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

2015-05-04 Thread Scott Gray

+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.bak...@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.

2015-05-04 Thread 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.

2015-05-04 Thread Adam Heath

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: move to git.

2015-04-30 Thread Jacques Le Roux


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.

2015-04-29 Thread Jacques Le Roux

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 pierre.sm...@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

Re: move to git.

2015-04-29 Thread gil portenseigne

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 pierre.sm...@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

Re: move to git.

2015-04-29 Thread Adam Heath



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.

2015-04-29 Thread Jacques Le Roux

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.

2015-04-28 Thread Adam Heath



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.

2015-04-28 Thread Jacques Le Roux



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.

2015-04-28 Thread Jacques Le Roux


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.

2015-04-28 Thread Jacques Le Roux


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.


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 gil.portensei...@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.


Le 23/04/2015 01:54, David E. Jones a écrit :

On 22 Apr 2015, at 16:49, Adam Heath doo...@brainfood.com wrote:


On 04/22/2015 06:13 PM, Jacopo Cappellato wrote:

On Apr 22, 2015, at 11:41 PM, Adam Heath doo...@brainfood.com wrote:


When this happened, we had to relicense the entire project from GPL to Apache 
2.0.

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


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 doo...@brainfood.com wrote:


When this happened, we had to relicense the entire project from GPL to Apache 
2.0.

Gr It was not GPL! :-)

Jacopo

Re: move to git.


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.


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.

2015-04-27 Thread Jacopo Cappellato

On Apr 27, 2015, at 3:16 PM, Jacques Le Roux jacques.le.r...@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.


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.

2015-04-25 Thread Jacopo Cappellato


On Apr 25, 2015, at 1:14 AM, Adam Heath doo...@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.

2015-04-25 Thread Pierre Smits

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.cappell...@hotwaxsystems.com wrote:


 On Apr 25, 2015, at 1:14 AM, Adam Heath doo...@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.

2015-04-25 Thread Taher Alkhateeb

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 pierre.sm...@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.cappell...@hotwaxsystems.com wrote: 

 On Apr 25, 2015, at 1:14 AM, Adam Heath doo...@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.

2015-04-24 Thread Adam Heath



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.

2015-04-23 Thread Adam Heath



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.

2015-04-23 Thread Adam Heath



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 adrian.c...@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 pierre.sm...@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.r...@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

Re: move to git.

2015-04-23 Thread Adam Heath



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.

2015-04-23 Thread Adrian Crum


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.c...@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 pierre.sm...@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.r...@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.

2015-04-23 Thread Scott Gray

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.c...@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 pierre.sm...@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.r...@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.

2015-04-23 Thread Scott Gray

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 adrian.c...@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.c...@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 pierre.sm...@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.r...@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

Re: move to git.

2015-04-23 Thread Adrian Crum


 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 adrian.c...@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.c...@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 pierre.sm...@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.r...@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

Re: move to git.

2015-04-23 Thread Martin Becker

 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 scott.g...@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 adrian.c...@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 pierre.sm...@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.r...@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.

2015-04-23 Thread Jacopo Cappellato

On Apr 23, 2015, at 11:42 AM, Martin Becker martin.bec...@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.

2015-04-23 Thread David E. Jones


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 e...@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 gil.portensei...@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.

2015-04-22 Thread Gil Portenseigne

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

2015-04-22 Thread Ean Schuessler

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 gil.portensei...@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.

2015-04-22 Thread Ean Schuessler

 From: Pierre Smits pierre.sm...@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.

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 e...@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 gil.portensei...@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.

2015-04-22 Thread David E. Jones


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 e...@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 gil.portensei...@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.

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 e...@brainfood.com wrote:

  From: Pierre Smits pierre.sm...@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.



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.

2015-04-22 Thread Ean Schuessler

 From: Pierre Smits pierre.sm...@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.

2015-04-22 Thread David E. Jones


 On 22 Apr 2015, at 16:49, Adam Heath doo...@brainfood.com wrote:
 
 
 On 04/22/2015 06:13 PM, Jacopo Cappellato wrote:
 On Apr 22, 2015, at 11:41 PM, Adam Heath doo...@brainfood.com wrote:
 
 When this happened, we had to relicense the entire project from GPL to 
 Apache 2.0.
 Gr 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.

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-23to=2013-05-03type=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.

2015-04-22 Thread David E. Jones


 On 22 Apr 2015, at 16:14, Pierre Smits pierre.sm...@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.

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



On 04/22/2015 06:13 PM, Jacopo Cappellato wrote:

On Apr 22, 2015, at 11:41 PM, Adam Heath doo...@brainfood.com wrote:


When this happened, we had to relicense the entire project from GPL to Apache 
2.0.

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

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

2015-04-22 Thread Jacopo Cappellato

On Apr 22, 2015, at 11:41 PM, Adam Heath doo...@brainfood.com wrote:

 When this happened, we had to relicense the entire project from GPL to Apache 
 2.0.

Gr It was not GPL! :-)

Jacopo

Re: move to git.

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

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.

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 e...@brainfood.com wrote:

 - Original Message -
  From: Jacques Le Roux jacques.le.r...@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.

2015-04-21 Thread Sharan Foga


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 pierre.sm...@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 e...@brainfood.com 
wrote:



- Original Message -

From: Jacques Le Roux jacques.le.r...@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

Re: move to git.

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 sharan.f...@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 pierre.sm...@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 e...@brainfood.com
 wrote:

  - Original Message -

 From: Jacques Le Roux jacques.le.r

Re: move to git.

Le 21/04/2015 02:08, Ean Schuessler a écrit :

- Original Message -

From: Jacques Le Roux jacques.le.r...@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.

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 sharan.f...@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 pierre.sm...@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.

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

Re: move to git.

2015-04-21 Thread Gil portenseigne


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 pierre.sm...@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

Re: move to git.

2015-04-21 Thread Jacopo Cappellato

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 pierre.sm...@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.cappell...@hotwaxsystems.com wrote:
 
 On Apr 21, 2015, at 12:59 PM, Adrian Crum 
 adrian.c...@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.

2015-04-21 Thread Taher Alkhateeb

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.r...@les7arts.com wrote:

 Le 21/04/2015 02:08, Ean Schuessler a écrit :

 - Original Message -

 From: Jacques Le Roux jacques.le.r...@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.

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 pierre.sm...@gmail.com
wrote:

Quoting:

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 e...@brainfood.com wrote:

- Original Message -
From: Jacques Le Roux jacques.le.r...@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.

2015-04-21 Thread Adrian Crum


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.r...@les7arts.com wrote:


Le 21/04/2015 02:08, Ean Schuessler a écrit :


- Original Message -


From: Jacques Le Roux jacques.le.r...@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

Re: move to git.

2015-04-21 Thread Adrian Crum


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.

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.

2015-04-21 Thread David E. Jones


 On 20 Apr 2015, at 23:21, Pierre Smits pierre.sm...@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 e...@brainfood.com wrote:
 
 - Original Message -
 From: Jacques Le Roux jacques.le.r...@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

Re: move to git.



Le 21/04/2015 12:02, David E. Jones a écrit :

On 20 Apr 2015, at 23:21, Pierre Smits pierre.sm...@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 e...@brainfood.com wrote:


- Original Message -

From: Jacques Le Roux jacques.le.r...@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

Re: move to git.

2015-04-21 Thread Ean Schuessler

Comments inline.

 From: David E. Jones d...@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.

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 e...@brainfood.com wrote:

 Comments inline.

  From: David E. Jones d...@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.