subject:"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. 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.

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 *
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-20 Thread Taher Alkhateeb

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"  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 *
> 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-20 Thread Adrian Crum

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

I am also familiar with Git.

Please don't project your uncertainties regarding the expertise and
experiences of other as their traits. And don't confuse advancement with
suitability. A rocket ship is more advanced than a bike. But that doesn't
mean it is suitable for more than just hauling stuff into space.

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Mon, Apr 20, 2015 at 12:19 PM, Adrian Crum <
adrian.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"  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 *
>>> 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-20 Thread Adrian Crum

That's the point I was trying to make. Our needs in this project are 
pretty basic, and Subversion handles those needs well. Git will merely 
make things unnecessarily complicated.


At ApacheCon, the motivations for switching to Git were not related to 
OFBiz project management, but were related to local management of 
OFBiz-based projects. The common complaint was connecting local Git 
repositories to the project's Subversion repository. So, switching the 
project to Git will make life easier for some.


Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/20/2015 11:31 AM, Pierre Smits wrote:

I am also familiar with Git.

Please don't project your uncertainties regarding the expertise and
experiences of other as their traits. And don't confuse advancement with
suitability. A rocket ship is more advanced than a bike. But that doesn't
mean it is suitable for more than just hauling stuff into space.

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Mon, Apr 20, 2015 at 12:19 PM, Adrian Crum <
adrian.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"  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 *
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.


I have used Git on a project last year for 9 months, enough to get an idea I 
believe.
I don't say it's bad by itself, I say it's bad for the community

Jacques

Le 20/04/2015 12:08, Taher Alkhateeb a écrit :

One of the most difficult and challenging issue with branches is _merging_
them. Git is a tool that is far more advanced in its feature set in that
area.

It seems some of the opinions expressed against git are due to
unfamiliarity. The only way to be convinced is to try it on an advanced
level as i don't think an email thread would be enough for convincing
anyone of the merits.

My 2 cents

Taher Alkhateeb
On Apr 20, 2015 12:54 PM, "Pierre Smits"  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 *
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.

+1, well summarised Adrian!

Jacques

Le 20/04/2015 12:39, Adrian Crum a écrit :
That's the point I was trying to make. Our needs in this project are pretty basic, and Subversion handles those needs well. Git will merely make
things unnecessarily complicated.

At ApacheCon, the motivations for switching to Git were not related to OFBiz project management, but were related to local management of OFBiz-based
projects. The common complaint was connecting local Git repositories to the project's Subversion repository. So, switching the project to Git will
make life easier for some.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/20/2015 11:31 AM, Pierre Smits wrote:

I am also familiar with Git.

Please don't project your uncertainties regarding the expertise and
experiences of other as their traits. And don't confuse advancement with
suitability. A rocket ship is more advanced than a bike. But that doesn't
mean it is suitable for more than just hauling stuff into space.

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Mon, Apr 20, 2015 at 12:19 PM, Adrian Crum <
adrian.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" 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 *
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.

@Jacques: is your +1 to be regarded as a yes vote fore moving to git? I am
getting confused somehow.

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Mon, Apr 20, 2015 at 1:01 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> +1, well summarised Adrian!
>
> Jacques
>
>
> Le 20/04/2015 12:39, Adrian Crum a écrit :
>
>> That's the point I was trying to make. Our needs in this project are
>> pretty basic, and Subversion handles those needs well. Git will merely make
>> things unnecessarily complicated.
>>
>> At ApacheCon, the motivations for switching to Git were not related to
>> OFBiz project management, but were related to local management of
>> OFBiz-based projects. The common complaint was connecting local Git
>> repositories to the project's Subversion repository. So, switching the
>> project to Git will make life easier for some.
>>
>> Adrian Crum
>> Sandglass Software
>> www.sandglass-software.com
>>
>> On 4/20/2015 11:31 AM, Pierre Smits wrote:
>>
>>> I am also familiar with Git.
>>>
>>> Please don't project your uncertainties regarding the expertise and
>>> experiences of other as their traits. And don't confuse advancement with
>>> suitability. A rocket ship is more advanced than a bike. But that doesn't
>>> mean it is suitable for more than just hauling stuff into space.
>>>
>>> Best regards,
>>>
>>> Pierre Smits
>>>
>>> *ORRTIZ.COM *
>>> Services & Solutions for Cloud-
>>> Based Manufacturing, Professional
>>> Services and Retail & Trade
>>> http://www.orrtiz.com
>>>
>>> On Mon, Apr 20, 2015 at 12:19 PM, Adrian Crum <
>>> adrian.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" 
> 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 *
>> 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

>>>

Re: move to git.


Sorry, I mean I second Adrian's explanation which is obviously not to vote for 
moving to Git
And If you read the thread you will see I already said: " a -1 if necessary!"

Jacques

Le 20/04/2015 13:05, Pierre Smits a écrit :

@Jacques: is your +1 to be regarded as a yes vote fore moving to git? I am
getting confused somehow.

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Mon, Apr 20, 2015 at 1:01 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


+1, well summarised Adrian!

Jacques


Le 20/04/2015 12:39, Adrian Crum a écrit :


That's the point I was trying to make. Our needs in this project are
pretty basic, and Subversion handles those needs well. Git will merely make
things unnecessarily complicated.

At ApacheCon, the motivations for switching to Git were not related to
OFBiz project management, but were related to local management of
OFBiz-based projects. The common complaint was connecting local Git
repositories to the project's Subversion repository. So, switching the
project to Git will make life easier for some.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/20/2015 11:31 AM, Pierre Smits wrote:


I am also familiar with Git.

Please don't project your uncertainties regarding the expertise and
experiences of other as their traits. And don't confuse advancement with
suitability. A rocket ship is more advanced than a bike. But that doesn't
mean it is suitable for more than just hauling stuff into space.

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Mon, Apr 20, 2015 at 12:19 PM, Adrian Crum <
adrian.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" 
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 *
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.

SVN allows for a local branching?  Believing git only allows this was
the main reason for my recent switch.  Are commit privileges not
necessary for the creation of such an svn branch as is the case with
git?

On Mon, 2015-04-20 at 11:54 +0200, Pierre Smits wrote:
> If we only want GIT for multiple local development branches, then we are
> doing for the wrong reasons. SVN doesn't hinder you in doing that today.
> 
> Best regards,
> 
> Pierre Smits
> 
> *ORRTIZ.COM *
> 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.


Le 20/04/2015 20:37, Christian Carlow a écrit :

SVN allows for a local branching?  Believing git only allows this was
the main reason for my recent switch.  Are commit privileges not
necessary for the creation of such an svn branch as is the case with
git?


No, clearly Git allows more than Svn (both cases above for instance), but it 
does not mean that its the solution for OFBiz

Note that you have also OFBiz at https://github.com/apache/ofbiz if you need 
local branching...

Jacques




On Mon, 2015-04-20 at 11:54 +0200, Pierre Smits wrote:

If we only want GIT for multiple local development branches, then we are
doing for the wrong reasons. SVN doesn't hinder you in doing that today.

Best regards,

Pierre Smits

*ORRTIZ.COM *
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.

Thanks for clarifying Jacques,

I switched to git a few weeks ago because it allows non-committers like
myself to develop as if having svn committer privilege.  Having the
ability to create and switch between branches for my JIRA issues was
very liberating and convenient for generating patches.  If svn cannot
provide non-committers the same freedom then the git switch seems more
worthy.

On Mon, 2015-04-20 at 20:55 +0200, Jacques Le Roux wrote:
> Le 20/04/2015 20:37, Christian Carlow a écrit :
> > SVN allows for a local branching?  Believing git only allows this was
> > the main reason for my recent switch.  Are commit privileges not
> > necessary for the creation of such an svn branch as is the case with
> > git?
> 
> No, clearly Git allows more than Svn (both cases above for instance), but it 
> does not mean that its the solution for OFBiz
> 
> Note that you have also OFBiz at https://github.com/apache/ofbiz if you need 
> local branching...
> 
> Jacques
> 
> 
> >
> > On Mon, 2015-04-20 at 11:54 +0200, Pierre Smits wrote:
> >> If we only want GIT for multiple local development branches, then we are
> >> doing for the wrong reasons. SVN doesn't hinder you in doing that today.
> >>
> >> Best regards,
> >>
> >> Pierre Smits
> >>
> >> *ORRTIZ.COM *
> >> 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-20 Thread Nicolas Malin


Le 20/04/2015 09:53, Adrian Crum a écrit :

I find Git to be an overly complicated solution to a simple problem.

I have the same feeling

Nicolas

Re: move to git.

I have currently multiple local development branches in our SVN and they
are SVN based and they are all of the same bases at
https://svn.apache.org/repos/asf/ofbiz.

And yes, I have commit privileges.

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Mon, Apr 20, 2015 at 8:37 PM, Christian Carlow <
christian.car...@gmail.com> wrote:

> SVN allows for a local branching?  Believing git only allows this was
> the main reason for my recent switch.  Are commit privileges not
> necessary for the creation of such an svn branch as is the case with
> git?
>
> On Mon, 2015-04-20 at 11:54 +0200, Pierre Smits wrote:
> > If we only want GIT for multiple local development branches, then we are
> > doing for the wrong reasons. SVN doesn't hinder you in doing that today.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *ORRTIZ.COM *
> > 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.

Thanks Pierre,

I switched to git because committer privileges don't have to be granted
before non-committers have access to development freedoms such as branch
creations for conveniencies such as patch creation.  Such a system seems
to promote more open source collaboration.

On Mon, 2015-04-20 at 21:49 +0200, Pierre Smits wrote:
> I have currently multiple local development branches in our SVN and they
> are SVN based and they are all of the same bases at
> https://svn.apache.org/repos/asf/ofbiz.
> 
> And yes, I have commit privileges.
> 
> Best regards,
> 
> Pierre Smits
> 
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
> 
> On Mon, Apr 20, 2015 at 8:37 PM, Christian Carlow <
> christian.car...@gmail.com> wrote:
> 
> > SVN allows for a local branching?  Believing git only allows this was
> > the main reason for my recent switch.  Are commit privileges not
> > necessary for the creation of such an svn branch as is the case with
> > git?
> >
> > On Mon, 2015-04-20 at 11:54 +0200, Pierre Smits wrote:
> > > If we only want GIT for multiple local development branches, then we are
> > > doing for the wrong reasons. SVN doesn't hinder you in doing that today.
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > *ORRTIZ.COM *
> > > 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.

Thanks for what, Christian?

Ah It seems you're misunderstanding me as I might have been a bit to
brief. I have commit privileges in other projects. I don't have that
privilege in this project.

By the way, I have seen your recent git coalescence/aggregation regarding
various issues into one big-sized patch. Affecting multiple components.
This is, I surmise, the result of the way Git is utilised as a change
integration tool from various private development branches before
submitting patches/promoted. Which is a bit harder to achieve in SVN.

At the moment I am not certain whether to llike or dislike the end result
(the patch in question).

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Mon, Apr 20, 2015 at 10:26 PM, Christian Carlow <
christian.car...@gmail.com> wrote:

> Thanks Pierre,
>
> I switched to git because committer privileges don't have to be granted
> before non-committers have access to development freedoms such as branch
> creations for conveniencies such as patch creation.  Such a system seems
> to promote more open source collaboration.
>
> On Mon, 2015-04-20 at 21:49 +0200, Pierre Smits wrote:
> > I have currently multiple local development branches in our SVN and they
> > are SVN based and they are all of the same bases at
> > https://svn.apache.org/repos/asf/ofbiz.
> >
> > And yes, I have commit privileges.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *ORRTIZ.COM *
> > Services & Solutions for Cloud-
> > Based Manufacturing, Professional
> > Services and Retail & Trade
> > http://www.orrtiz.com
> >
> > On Mon, Apr 20, 2015 at 8:37 PM, Christian Carlow <
> > christian.car...@gmail.com> wrote:
> >
> > > SVN allows for a local branching?  Believing git only allows this was
> > > the main reason for my recent switch.  Are commit privileges not
> > > necessary for the creation of such an svn branch as is the case with
> > > git?
> > >
> > > On Mon, 2015-04-20 at 11:54 +0200, Pierre Smits wrote:
> > > > If we only want GIT for multiple local development branches, then we
> are
> > > > doing for the wrong reasons. SVN doesn't hinder you in doing that
> today.
> > > >
> > > > Best regards,
> > > >
> > > > Pierre Smits
> > > >
> > > > *ORRTIZ.COM *
> > > > 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.

As always, thanks for the feedback ;)

On Mon, 2015-04-20 at 23:07 +0200, Pierre Smits wrote:
> Thanks for what, Christian?
> 
> Ah It seems you're misunderstanding me as I might have been a bit to
> brief. I have commit privileges in other projects. I don't have that
> privilege in this project.
> 
> By the way, I have seen your recent git coalescence/aggregation regarding
> various issues into one big-sized patch. Affecting multiple components.
> This is, I surmise, the result of the way Git is utilised as a change
> integration tool from various private development branches before
> submitting patches/promoted. Which is a bit harder to achieve in SVN.
> 
> At the moment I am not certain whether to llike or dislike the end result
> (the patch in question).
> 
> Best regards,
> 
> Pierre Smits
> 
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
> 
> On Mon, Apr 20, 2015 at 10:26 PM, Christian Carlow <
> christian.car...@gmail.com> wrote:
> 
> > Thanks Pierre,
> >
> > I switched to git because committer privileges don't have to be granted
> > before non-committers have access to development freedoms such as branch
> > creations for conveniencies such as patch creation.  Such a system seems
> > to promote more open source collaboration.
> >
> > On Mon, 2015-04-20 at 21:49 +0200, Pierre Smits wrote:
> > > I have currently multiple local development branches in our SVN and they
> > > are SVN based and they are all of the same bases at
> > > https://svn.apache.org/repos/asf/ofbiz.
> > >
> > > And yes, I have commit privileges.
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > *ORRTIZ.COM *
> > > Services & Solutions for Cloud-
> > > Based Manufacturing, Professional
> > > Services and Retail & Trade
> > > http://www.orrtiz.com
> > >
> > > On Mon, Apr 20, 2015 at 8:37 PM, Christian Carlow <
> > > christian.car...@gmail.com> wrote:
> > >
> > > > SVN allows for a local branching?  Believing git only allows this was
> > > > the main reason for my recent switch.  Are commit privileges not
> > > > necessary for the creation of such an svn branch as is the case with
> > > > git?
> > > >
> > > > On Mon, 2015-04-20 at 11:54 +0200, Pierre Smits wrote:
> > > > > If we only want GIT for multiple local development branches, then we
> > are
> > > > > doing for the wrong reasons. SVN doesn't hinder you in doing that
> > today.
> > > > >
> > > > > Best regards,
> > > > >
> > > > > Pierre Smits
> > > > >
> > > > > *ORRTIZ.COM *
> > > > > 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-20 Thread Ean Schuessler

- Original Message -
> From: "Jacques Le Roux" 
> 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-20 Thread Adam Heath

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.

2015-04-20 Thread Adam Heath



On 04/20/2015 07:12 PM, Adam Heath wrote:
I used to be in the same boat; in the early days, I would blame git 
for losing my work.  "Damn you frigging piece of software!"


However, I also realized that the linux-kernel was using it to do much 
more complex things than I was, so I toiled on.  It took me a long 
time, but I was finally able to figure out how to make use of git's 
features.


The main thing that keeps you from losing work, is to commit 
*everything* to git.  If you leave *anything* in your $working_tree, 
not committed, then yes, sometimes things get confused.  But once you 
have everything committed to git, there are certain things that git 
helps you with, with regard to keeping copies of stuff around.


==
# git config --global rerere.enabled true
# (echo adfadsfasdf; date) > new-file
# git branch before-new-file
# git add new-file
# git commit -m "This is my cool new file, yipee!"
# git log
# git checkout before-new-file
# git branch -f master before-new-file
# git checkout master
# ls new-file  # hmm, where did it go?
# git reflog # hmm, seems to show the commit from above
# git log trunk # commit is gone
# git log trunk@{1} # this shows the commit, and the file
==



Gah, too many git features.  git rerere is a feature to cache rebase 
resolutions; the feature being discussed here is not the same thing.


This is just one of the powerful features that git has.  I have rerere 
enabled locally, but don't use it often.  I enabled it long ago, 
because I saw that it keeps copies of all my rebasing and branching, 
so that I can feel safer about having this safety net.


Also, I when back in time, and found an older copy of the previous 
ofbiz svn tree, and "underlayed" it into the current git-svn checkout, 
so I have git history going all the way back to 2003.


On 04/20/2015 02:53 AM, Adrian Crum wrote:

I don't agree that "all major contributors are using git."

Personally, I find Git to be an overly complicated solution to a 
simple problem. It frequently does bizarre things that no one 
understands, and you are left with things being mysteriously reverted 
for unknown reasons.


This isn't a -1 vote though. I'm just making it clear that I will be 
dragged kicking and screaming into using it.


Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/20/2015 5:38 AM, Hans Bakker wrote:
As discussed at apachecon in Austin, i propose to switch from svn to 
git

for the ofbiz repository. The main reason being that all major
contributors are using git and contributions are cumbersome, further,
git allows for better branching and merging.

Regards,
Hans

Re: move to git.

2015-04-20 Thread Adam Heath



On 04/20/2015 04:12 AM, Jacques Le Roux wrote:

Like Adrian and mostly for the same reasons, I don't believe we need Git.

But there is one other major reason which has already been discussed 
in the other common ASF MLs.  As Taher exulted, it's possible to 
create local branches. So people are able to do a lot of work alone 
without exchanging before committing or submitting. It will certainly 
not help to have this possibility. Remember our recent discussion on 
the lack or core commits reviews. With Git you end with commits bursts 
or big patches and it's then hard to review and too late to share ideas.




I take exception to this; I believe you are referring to my commit 
bursts, in times past.  Aka, 10-15 commits get added to svn in under a 
minute.


Git allows me to create a new feature, initially as a single large 
commit(or several large commits).  Then, using the rebase feature, I 
pull out very small changes, that are easy to understand, and digest.  I 
then might commit those as completely separate fixes/feature-additions, 
which then get reviewed.  I then wait a bit, and rebase my big work on 
top of the new trunk.


Eventually, I get the history to such a point that I feel that the 
series of commits are an easy to understand progression.  At that point, 
I commit the entire set to svn.


Note, that I run the entire set of test cases(as they exist at that 
point) against each and every single commit, before I send them off.


Having each commit separate, allows for each change to be looked at in 
isolation.  If they were all combined into one, then it would be much 
more difficult to review.


If the number of commits at once is the problem, then I don't follow.  
Spreading each commit out over several hours still won't cause anything 
to get reviewed.

Re: move to git.

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  wrote:

> - Original Message -
> > From: "Jacques Le Roux" 
> > 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.

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

- Original Message -

From: "Jacques Le Roux" 
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.

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

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.

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 
wrote:

> Quoting:
>
> We are also prepared to be assertive regarding this situation. If the
> project
> does not move to GIT then Brainfood is willing to participate in a
> consortium of
> organizations that will peer with each other to share updates to the master
> branch for their local OFBiz repository. Such an arrangement will,
> effectively,
> result in a distributed master repository image.
>
> Thanks Ean for the position of *Brainfood* in this position. It comes
> across as 'Do it our way, or else'. You are free to make such statements
> and when followed through there will be consequences. For all participating
> in this project. One I can see standing out clearly is: no more
> participation in/contribution from the employees of Brainfood and from the
> other companies in that consortium back into the project.
>
> If that is going to happen, I will say: 'I thank you for all the
> contributions you did to the project'. And I will check in my sentiments at
> the door. I do hope that if you do you also resign totally from this
> project.
>
>
> I rather have the community comes to its decision based on sound/valid
> arguments, not (veiled) threats.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM <http://www.orrtiz.com>*
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler  wrote:
>
>> - Original Message -
>> > From: "Jacques Le Roux" 
>> > 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" 
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 r

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.

2015-04-21 Thread David E. Jones

> On 20 Apr 2015, at 23:21, Pierre Smits  wrote:
> 
> Quoting:
> 
> We are also prepared to be assertive regarding this situation. If the
> project
> does not move to GIT then Brainfood is willing to participate in a
> consortium of
> organizations that will peer with each other to share updates to the master
> branch for their local OFBiz repository. Such an arrangement will,
> effectively,
> result in a distributed master repository image.
> 
> Thanks Ean for the position of *Brainfood* in this position. It comes
> across as 'Do it our way, or else'. You are free to make such statements
> and when followed through there will be consequences. For all participating
> in this project. One I can see standing out clearly is: no more
> participation in/contribution from the employees of Brainfood and from the
> other companies in that consortium back into the project.

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  wrote:
> 
>> - Original Message -
>>> From: "Jacques Le Roux" 
>>> 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
&

Re: move to git.



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

On 20 Apr 2015, at 23:21, Pierre Smits  wrote:

Quoting:

We are also prepared to be assertive regarding this situation. If the
project
does not move to GIT then Brainfood is willing to participate in a
consortium of
organizations that will peer with each other to share updates to the master
branch for their local OFBiz repository. Such an arrangement will,
effectively,
result in a distributed master repository image.

Thanks Ean for the position of *Brainfood* in this position. It comes
across as 'Do it our way, or else'. You are free to make such statements
and when followed through there will be consequences. For all participating
in this project. One I can see standing out clearly is: no more
participation in/contribution from the employees of Brainfood and from the
other companies in that consortium back into the project.

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  wrote:


----- Original Message -

From: "Jacques Le Roux" 
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

Re: move to git.

Le 21/04/2015 02:26, Adam Heath a écrit :

On 04/20/2015 04:12 AM, Jacques Le Roux wrote:

Like Adrian and mostly for the same reasons, I don't believe we need Git.

But there is one other major reason which has already been discussed in the other common ASF MLs. As Taher exulted, it's possible to create local
branches. So people are able to do a lot of work alone without exchanging before committing or submitting. It will certainly not help to have this
possibility. Remember our recent discussion on the lack or core commits reviews. With Git you end with commits bursts or big patches and it's then
hard to review and too late to share ideas.

I take exception to this; I believe you are referring to my commit bursts, in
times past. Aka, 10-15 commits get added to svn in under a minute.

Git allows me to create a new feature, initially as a single large commit(or several large commits). Then, using the rebase feature, I pull out
very small changes, that are easy to understand, and digest. I then might commit those as completely separate fixes/feature-additions, which then
get reviewed. I then wait a bit, and rebase my big work on top of the new trunk.

Eventually, I get the history to such a point that I feel that the series of commits are an easy to understand progression. At that point, I commit
the entire set to svn.

Note, that I run the entire set of test cases(as they exist at that point)
against each and every single commit, before I send them off.

Having each commit separate, allows for each change to be looked at in isolation. If they were all combined into one, then it would be much more
difficult to review.

If the number of commits at once is the problem, then I don't follow. Spreading each commit out over several hours still won't cause anything to
get reviewed.

I can see your point and it's difficult to not agree. I though have still a feeling that with Git spirit less things will be shared and discussed
before being committed

Jacques

Re: move to git.

Quoting:

they basically have to be extracted into a patch file and submitted through
a Jira issue


Which is a good approach with respect to improvements of the other kind
(improvements, not bug fixes) as they than can be assessed, regarding
applicability in light of the direction of the project and its works, by
all in the community. And not through some filtering mech of the various
subsets (of controlling/directing/dictating entities) of the community
before the contribution of the individual gets to the project.

It is the amalgamation/aggregation in the hierarchy described (by David)
that should be of more concern than the mere technical aspects of the tool
applied.

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Tue, Apr 21, 2015 at 12:19 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

>
> Le 21/04/2015 12:02, David E. Jones a écrit :
>
>> On 20 Apr 2015, at 23:21, Pierre Smits  wrote:
>>>
>>> Quoting:
>>>
>>> We are also prepared to be assertive regarding this situation. If the
>>> project
>>> does not move to GIT then Brainfood is willing to participate in a
>>> consortium of
>>> organizations that will peer with each other to share updates to the
>>> master
>>> branch for their local OFBiz repository. Such an arrangement will,
>>> effectively,
>>> result in a distributed master repository image.
>>>
>>> Thanks Ean for the position of *Brainfood* in this position. It comes
>>> across as 'Do it our way, or else'. You are free to make such statements
>>> and when followed through there will be consequences. For all
>>> participating
>>> in this project. One I can see standing out clearly is: no more
>>> participation in/contribution from the employees of Brainfood and from
>>> the
>>> other companies in that consortium back into the project.
>>>
>> 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 n

Re: move to git.



Le 21/04/2015 10:19, Taher Alkhateeb a écrit :

Hi Jacques and all,

I think that sharing more than anything is a reason why git has an
advantage. The distributed system means that every developer is a
repository and therefore you can have endless chains of code propagation up
to a committer. Just imagine a scenario like the following

- A team is composed of people working on a major task
- Two of the members (A and B) have their own sub-teams
- There is exchange of code between the sub-teams, the major team and the
project committer. Furthermore, the sub-teams need to pull updated data
from the main repository of the project.

So you have two integrators at the sub-team level and one integrator at the
top team level plus a project committer. Sometimes, I want to pull code
from the sub-team. Sometimes I want to pull code from the _other_ team.
Then maybe I want to _merge_ work from both teams and run all tests. Then I
want to clean the commit log with "git rebase" to cleanup the history into
major commits to submit to the project committer. Now the project owner
does not know / trust me but he knows / trusts you. And you in turn trust
me so you can accept my commits.

I cannot imagine how to implement the above without a distributed source
code management system. Furthermore, it's important to note that ofbiz is
not a closed proprietary project with a sacred repository hidden in the
vault of some company. You _need_ contributions from others and you need to
make it very easy and accessible. You need to have the ability for people
to form teams and sub-teams to support you and your project by
collaborating with each other without needing a committer. This is one of
the main reasons for the massive success of the Linux Kernel where each of
Linus Torvald's lieutenants is a committer for a sub-system with his/her
own people they trust and work closely with. Some of this stuff is briefly
shown in here http://www.git-scm.com/about/distributed

I hope what I wrote is resonating with you and you're willing to give this
idea a chance


OK, you kind of answered to my questions to Adam, I need to re-read carefully...

Jacques



Taher Alkhateeb

On Tue, Apr 21, 2015 at 10:23 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


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


- Original Message -


From: "Jacques Le Roux" 
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.

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  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  
wrote:



- Original Message -

From: "Jacques Le Roux" 
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

co

Re: move to git.



Le 21/04/2015 11:08, Adrian Crum a écrit :

Taher,

Nothing in your reply is new or different. People have been doing that for 
years with Subversion. Git did not invent local repositories.

Connecting a local Git repository to the OFBiz Subversion repository is a 
problem for some, that is why we are having this discussion.

So far, two proposals have been made:

1. Switch the OFBiz project to Git.
2. Host a separate Git repo that is a copy of the OFBiz Subversion repo.

How those proposals affect OFBiz developers:

1. Subversion users must switch to Git clients and learn Git.
2. Git users can access the project through the Git repo, Subversion users 
continue using Subversion with the main OFBiz repo.

Switching the main repo to Git does not add anything to the project itself. As I said before, Subversion handles our simple needs just fine. If 
Jacopo said something like, "Managing our releases is impossible with Subversion, we really need to switch to Git" - then we wouldn't be having this 
discussion, it would just happen because the need for the switch is obvious.


But Jacopo is not saying that, and we don't have a problem using Subversion to 
manage the project.


I don't remember Jacopo proposed to move to Git, it was Hans, then Taher, Adam and Ean seconded. I guess Taher, AntWeb and Brainfood are using Git and 
they would like to see OFBiz using it as well.


I have been using a Git repo for a custom project. I simply put the OFBiz .svn 
in the Git working copy and repo et voilà.
I had the best of both world, I could easily backport my contributions in 
OFBiz. It's also very convenient for other reasons.
I must admit it's not available for non committers who have to create patches, 
nothing new..

Jacques




Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/21/2015 9:19 AM, Taher Alkhateeb wrote:

Hi Jacques and all,

I think that sharing more than anything is a reason why git has an
advantage. The distributed system means that every developer is a
repository and therefore you can have endless chains of code propagation up
to a committer. Just imagine a scenario like the following

- A team is composed of people working on a major task
- Two of the members (A and B) have their own sub-teams
- There is exchange of code between the sub-teams, the major team and the
project committer. Furthermore, the sub-teams need to pull updated data
from the main repository of the project.

So you have two integrators at the sub-team level and one integrator at the
top team level plus a project committer. Sometimes, I want to pull code
from the sub-team. Sometimes I want to pull code from the _other_ team.
Then maybe I want to _merge_ work from both teams and run all tests. Then I
want to clean the commit log with "git rebase" to cleanup the history into
major commits to submit to the project committer. Now the project owner
does not know / trust me but he knows / trusts you. And you in turn trust
me so you can accept my commits.

I cannot imagine how to implement the above without a distributed source
code management system. Furthermore, it's important to note that ofbiz is
not a closed proprietary project with a sacred repository hidden in the
vault of some company. You _need_ contributions from others and you need to
make it very easy and accessible. You need to have the ability for people
to form teams and sub-teams to support you and your project by
collaborating with each other without needing a committer. This is one of
the main reasons for the massive success of the Linux Kernel where each of
Linus Torvald's lieutenants is a committer for a sub-system with his/her
own people they trust and work closely with. Some of this stuff is briefly
shown in here http://www.git-scm.com/about/distributed

I hope what I wrote is resonating with you and you're willing to give this
idea a chance

Taher Alkhateeb

On Tue, Apr 21, 2015 at 10:23 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


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


----- Original Message -


From: "Jacques Le Roux" 
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 di

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

Re: move to git.

2015-04-21 Thread Jacopo Cappellato

On Apr 21, 2015, at 11:23 AM, Jacques Le Roux  
wrote:

>> Switching the main repo to Git does not add anything to the project itself. 
>> As I said before, Subversion handles our simple needs just fine. If Jacopo 
>> said something like, "Managing our releases is impossible with Subversion, 
>> we really need to switch to Git" - then we wouldn't be having this 
>> discussion, it would just happen because the need for the switch is obvious.
>> 
>> But Jacopo is not saying that, and we don't have a problem using Subversion 
>> to manage the project.
> 
> I don't remember Jacopo proposed to move to Git, it was Hans, then Taher, 
> Adam and Ean seconded. I guess Taher, AntWeb and Brainfood are using Git and 
> they would like to see OFBiz using it as well.

In fact I didn't express my opinion or preference.
At Hotwax we use Git for all our projects and we are happy with it. But this 
doesn't mean that svn is bad or old or not a good tool for OFBiz.
In fact, as I mentioned to Hans at ApacheCon, before discussing "svn vs git" as 
mere tools, it would be more interesting and useful to review/discuss the 
contribution/commit workflows that these tools can enable and see if there is a 
room for a better workflow for the project.

Jacopo

Re: move to git.

2015-04-21 Thread Adrian Crum


Everyone is missing the point I am trying to make.

I said, "***IF*** Jacopo said something like..."

As the OFBiz RM, ***IF*** Jacopo said he couldn't use Subversion to 
manage the OFBiz project, then the need to switch to something else 
would be obvious.


I hope that clarifies my true meaning.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/21/2015 11:55 AM, Jacopo Cappellato wrote:

On Apr 21, 2015, at 11:23 AM, Jacques Le Roux  
wrote:


Switching the main repo to Git does not add anything to the project itself. As I said 
before, Subversion handles our simple needs just fine. If Jacopo said something like, 
"Managing our releases is impossible with Subversion, we really need to switch to 
Git" - then we wouldn't be having this discussion, it would just happen because the 
need for the switch is obvious.

But Jacopo is not saying that, and we don't have a problem using Subversion to 
manage the project.


I don't remember Jacopo proposed to move to Git, it was Hans, then Taher, Adam 
and Ean seconded. I guess Taher, AntWeb and Brainfood are using Git and they 
would like to see OFBiz using it as well.


In fact I didn't express my opinion or preference.
At Hotwax we use Git for all our projects and we are happy with it. But this 
doesn't mean that svn is bad or old or not a good tool for OFBiz.
In fact, as I mentioned to Hans at ApacheCon, before discussing "svn vs git" as 
mere tools, it would be more interesting and useful to review/discuss the 
contribution/commit workflows that these tools can enable and see if there is a room for 
a better workflow for the project.

Jacopo

Re: move to git.


That's indeed what needs to be discussed and that why I asked OFBiz-France 
members opinions

Jacques

Le 21/04/2015 12:52, Pierre Smits a écrit :

Sharing those improvements as patches attached to JIRA issues is a way
better mechanism for exposure and review than through the distributed and
competing search/find tools of today (Google et all) into all the
distributed repositories or forks.

Best regards,

Pierre.

Op dinsdag 21 april 2015 heeft Sharan Foga  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  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,

Re: move to git.

Thanks for clarification Adrian,

I did not think about the Release Manager role

Jacques

Le 21/04/2015 12:59, Adrian Crum a écrit :

Everyone is missing the point I am trying to make.

I said, "***IF*** Jacopo said something like..."

As the OFBiz RM, ***IF*** Jacopo said he couldn't use Subversion to manage the OFBiz project, then the need to switch to something else would be
obvious.

I hope that clarifies my true meaning.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/21/2015 11:55 AM, Jacopo Cappellato wrote:

On Apr 21, 2015, at 11:23 AM, Jacques Le Roux
wrote:

Switching the main repo to Git does not add anything to the project itself. As I said before, Subversion handles our simple needs just fine. If
Jacopo said something like, "Managing our releases is impossible with Subversion, we really need to switch to Git" - then we wouldn't be having
this discussion, it would just happen because the need for the switch is obvious.

But Jacopo is not saying that, and we don't have a problem using Subversion to
manage the project.

I don't remember Jacopo proposed to move to Git, it was Hans, then Taher, Adam and Ean seconded. I guess Taher, AntWeb and Brainfood are using Git
and they would like to see OFBiz using it as well.

In fact I didn't express my opinion or preference.
At Hotwax we use Git for all our projects and we are happy with it. But this
doesn't mean that svn is bad or old or not a good tool for OFBiz.
In fact, as I mentioned to Hans at ApacheCon, before discussing "svn vs git" as mere tools, it would be more interesting and useful to
review/discuss the contribution/commit workflows that these tools can enable and see if there is a room for a better workflow for the project.

Jacopo

Re: move to git.

2015-04-21 Thread Jacopo Cappellato

On Apr 21, 2015, at 12:59 PM, Adrian Crum  
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.

@Adrian: I didn't miss your point! Opted not to respond, as I saw nothing
wrong with/in the assertion/point you posted.

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Tue, Apr 21, 2015 at 12:59 PM, Adrian Crum <
adrian.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
> Sandglass Software
> www.sandglass-software.com
>
> On 4/21/2015 11:55 AM, Jacopo Cappellato wrote:
>
>> On Apr 21, 2015, at 11:23 AM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>>  Switching the main repo to Git does not add anything to the project
>>>> itself. As I said before, Subversion handles our simple needs just fine. If
>>>> Jacopo said something like, "Managing our releases is impossible with
>>>> Subversion, we really need to switch to Git" - then we wouldn't be having
>>>> this discussion, it would just happen because the need for the switch is
>>>> obvious.
>>>>
>>>> But Jacopo is not saying that, and we don't have a problem using
>>>> Subversion to manage the project.
>>>>
>>>
>>> I don't remember Jacopo proposed to move to Git, it was Hans, then
>>> Taher, Adam and Ean seconded. I guess Taher, AntWeb and Brainfood are using
>>> Git and they would like to see OFBiz using it as well.
>>>
>>
>> In fact I didn't express my opinion or preference.
>> At Hotwax we use Git for all our projects and we are happy with it. But
>> this doesn't mean that svn is bad or old or not a good tool for OFBiz.
>> In fact, as I mentioned to Hans at ApacheCon, before discussing "svn vs
>> git" as mere tools, it would be more interesting and useful to
>> review/discuss the contribution/commit workflows that these tools can
>> enable and see if there is a room for a better workflow for the project.
>>
>> Jacopo
>>
>>

Re: move to git.

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.

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

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

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  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 Ean Schuessler

Comments inline.


> From: "Pierre Smits" 
> Subject: Re: move to git.

> Quoting:
> We are also prepared to be assertive regarding this situation. 



> Thanks Ean for the position of *Brainfood* in this position. It comes
> across as 'Do it our way, or else'. You are free to make such statements
> and when followed through there will be consequences. For all participating
> in this project. One I can see standing out clearly is: no more
> participation in/contribution from the employees of Brainfood and from the
> other companies in that consortium back into the project.
> 
> If that is going to happen, I will say: 'I thank you for all the
> contributions you did to the project'. And I will check in my sentiments at
> the door. I do hope that if you do you also resign totally from this
> project.

I believe what I said was "we'll do it our way even if you continue to do it
your way". I'm not sure what the "or else" part of my message was. I would ask
you to explain that to me but I'm not sure its important to the discussion.

> I rather have the community comes to its decision based on sound/valid
> arguments, not (veiled) threats.

There were no threats in my message. A threat might read like "no participation
in/contribution from {insert group here} will be allowed if they try to do
something without my permission".

The Apache Way is to "be nice" and I think it would be nice if people could
pursue their own ideas about how to improve the project as long as they do not
coerce other members.

Re: move to git.

2015-04-21 Thread Ean Schuessler

Comments inline.

> From: "David E. Jones" 
> 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  wrote:

> Comments inline.
>
> > From: "David E. Jones" 
> > 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.


Le 21/04/2015 16:00, Pierre Smits a écrit :

Quoting:

At Apachecon, Apache's engineering and corporate leadership advised me that
we
could move to using OFBiz to manage our issues instead of JIRA if we so
desire.


If we want to explore that path, I suggest we do that in a separate thread.


Please don't, so we would not only move to Git and/or Maven and/or Moqui but 
while doing so we would also compete with Jira? :-o

Jacques



Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Tue, Apr 21, 2015 at 3:35 PM, Ean Schuessler  wrote:


Comments inline.


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

2015-04-21 Thread Ron Wheeler


On 21/04/2015 6:55 AM, Jacopo Cappellato wrote:

On Apr 21, 2015, at 11:23 AM, Jacques Le Roux  
wrote:


Switching the main repo to Git does not add anything to the project itself. As I said 
before, Subversion handles our simple needs just fine. If Jacopo said something like, 
"Managing our releases is impossible with Subversion, we really need to switch to 
Git" - then we wouldn't be having this discussion, it would just happen because the 
need for the switch is obvious.

But Jacopo is not saying that, and we don't have a problem using Subversion to 
manage the project.

I don't remember Jacopo proposed to move to Git, it was Hans, then Taher, Adam 
and Ean seconded. I guess Taher, AntWeb and Brainfood are using Git and they 
would like to see OFBiz using it as well.

In fact I didn't express my opinion or preference.
At Hotwax we use Git for all our projects and we are happy with it. But this 
doesn't mean that svn is bad or old or not a good tool for OFBiz.
In fact, as I mentioned to Hans at ApacheCon, before discussing "svn vs git" as 
mere tools, it would be more interesting and useful to review/discuss the 
contribution/commit workflows that these tools can enable and see if there is a room for 
a better workflow for the project.

Jacopo


I think that this is a very good summary of the issue.

It appears to me that there is a fundamental shift of philosophy that 
"Move to git" is discussing rather than a tool switch.


With git it is much easier to develop parallel "products".
I could chose to follow Jacopo's public repo or Ean's rather than the 
"official" OFBiz repo if I felt that they were doing things that I liked 
that were not being committed to the OFBiz repo.
I could take changes from more than one repo if I felt that I could 
handle the integration workload and maintain a blended product.


I could make changes and request that any other repo that wanted to have 
them, take them but I have no guarantee that Jacopo, Ean or OFBiz would 
accept them.

I could use the Apache JIRA to document my patch or not.
Clearly a JIRA issue would get more discussion and might cause me to 
revise my "contribution" or make it more likely to be accepted if the 
concensus is that it is a "good thing".


I could create my own issue tracking system and invite others to look 
there for my ideas.


Each one of the versions could have its own release schedule.

This is substantially different that the current situation and I think 
that Jacopo's suggested course of action of looking at the proposal as a 
question of workflow is a good idea.
Underlying this discussion, there is a dissatisfaction with the workflow 
expressed by people who are not committers (in general).
There are a lot of private forks of OFBiz already but most of the ones 
that show up here are based on the OFBiz trunk and are produced by 
committers who contribute back some of their local changes.


In some ways, moving to a more distributed system, does help make OFBiz 
stronger. The keepers of the OFBiz repo have control as they do now 
about what changes get incorporated into the OFBiz "trunk". Others can 
continue to use the contributions to the trunk but are still able to use 
"improvements" from other repos that have been rejected by the community.


There are licensing issues that I would have to deal with as a 
maintainer of a private repo if I start to include work from non-Apache 
repos since I can not be quite so sure that the contributions to the 
private repo have been released to me under an Apache license.


I am not advocating a shift to git, just trying to support Jacopo's 
suggestion of looking at workflow first with a slight addition of 
extending the discussion to project management philosophy since that 
seems to be a key motivation underlying the suggestion to move.


Ron



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: move to git.

2015-04-21 Thread Hans Bakker

Tough time ahead Jacques, these were exactly the 4 major subjects 
informally discussed in Austin.


It also shows that programmers like to change the world of the 
end-users, however forget to improve themselves the way they work


Regards,
Hans

On 21/04/15 21:23, Jacques Le Roux wrote:

Le 21/04/2015 16:00, Pierre Smits a écrit :

Quoting:

At Apachecon, Apache's engineering and corporate leadership advised 
me that

we
could move to using OFBiz to manage our issues instead of JIRA if we so
desire.


If we want to explore that path, I suggest we do that in a separate 
thread.


Please don't, so we would not only move to Git and/or Maven and/or 
Moqui but while doing so we would also compete with Jira? :-o


Jacques

Re: move to git.

2015-04-21 Thread Ron Wheeler

I am not sure that this should come as a surprise or a real difference 
in the current state.

It is possible for anyone to fork the project.
With git it could be easier to contribute back changes from this fork.
Of course, the code bases could diverge to a point where sharing updates 
becomes too complex for both sides.


The real issue is whether there is sufficient dissatisfaction with the 
current workflow and product direction for another community of 
like-minded committers to build to a size capable of managing a "better" 
fork.


Ron



On 21/04/2015 2:21 AM, Pierre Smits wrote:

Quoting:

We are also prepared to be assertive regarding this situation. If the
project
does not move to GIT then Brainfood is willing to participate in a
consortium of
organizations that will peer with each other to share updates to the master
branch for their local OFBiz repository. Such an arrangement will,
effectively,
result in a distributed master repository image.

Thanks Ean for the position of *Brainfood* in this position. It comes
across as 'Do it our way, or else'. You are free to make such statements
and when followed through there will be consequences. For all participating
in this project. One I can see standing out clearly is: no more
participation in/contribution from the employees of Brainfood and from the
other companies in that consortium back into the project.

If that is going to happen, I will say: 'I thank you for all the
contributions you did to the project'. And I will check in my sentiments at
the door. I do hope that if you do you also resign totally from this
project.


I rather have the community comes to its decision based on sound/valid
arguments, not (veiled) threats.

Best regards,

Pierre Smits

*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler  wrote:


- Original Message -

From: "Jacques Le Roux" 
Subject: Re: move to git.
Like Adrian and mostly for the same reasons, I don't believe we need Git.

But there is one other major reason which has already been discussed in

the

other common ASF MLs.  As Taher exulted, it's possible to create local
branches. So people are able to do a lot of work alone without

exchanging before

committing or submitting. It will certainly not help to have this
possibility.

I disagree. It is useful in many situations for OFBiz developers to create
a
local repository that is not globally shared. Some customers may even
require
such a situation for security or legal reasons.


Remember our recent discussion on the lack or core commits reviews.
With Git you end with commits bursts or big patches and it's then
hard to review and too late to share ideas.

So unlike Adrian, I'm even strongly against it. I will not hesitate to

use a -1

if necessary!

We are also prepared to be assertive regarding this situation. If the
project
does not move to GIT then Brainfood is willing to participate in a
consortium of
organizations that will peer with each other to share updates to the master
branch for their local OFBiz repository. Such an arrangement will,
effectively,
result in a distributed master repository image.

If anyone else is interested in such an arrangement please feel free to
speak
up and we can begin the planning process.




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: move to git.

2015-04-21 Thread Adam Heath



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.


Le 21/04/2015 17:53, Hans Bakker a écrit :
It also shows that programmers like to change the world of the end-users, however forget to improve themselves the way they work 

Are you insinuating that I'm fossilised and against changes in order to improve 
the way I work? If so you are wrong!

Jacques
PS: I will be totally off for 3 days for personal reasons, so don't expect more 
posts from me before Sunday evening... Have fun...

Re: move to git.

2015-04-21 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  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" 
> Subject: Re: move to git.

> Yes, but these are commiters contributions, i mean non-commiters one should go
> thru 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  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" 
> > 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  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" 
>> 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" 
> 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.

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  wrote:

> > From: "Pierre Smits" 
> > 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" 
> 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.

It occasionally happens that committers don't reference the contributors.
But that is seldom.

Best regards,

Pierre Smits

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

Github shows the committers as contributors. The links I provided just
shows a better overview of those contributors.

Best regards,

Pierre Smits

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

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

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 *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

Re: move to git.



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

On Apr 22, 2015, at 11:41 PM, Adam Heath  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.

2015-04-22 Thread David E. Jones

> On 22 Apr 2015, at 16:49, Adam Heath  wrote:
> 
> 
> On 04/22/2015 06:13 PM, Jacopo Cappellato wrote:
>> On Apr 22, 2015, at 11:41 PM, Adam Heath  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.

2015-04-22 Thread David E. Jones


> On 22 Apr 2015, at 16:14, 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.

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.

https://github.com/ansible/ansible/graphs/contributors

mpdehaan used to be *the* ansible guy. It was his original creation.
He has since moved on, but 1000 contributors that have actual code
inside the primary repository.

Also look at
https://github.com/ansible/ansible/graphs/contributors?from=2012-11-23&to=2013-05-03&type=c,
which shows how you can have a draggable window; but having a nice gui
is not what this sub-discussion is about.

On 04/22/2015 06:14 PM, Pierre Smits wrote:

Indeed, let's not amalgamate everything and keep the discussion clean. The
https://fisheye6.atlassian.com/graph/ofbiz does show information about the
jira issue (including the contributor, if done correctly). Just click on
the blue i icon to the right of the comment excerpt. You'll see a modal
window appearing with more info. Take as an example the commit done on
April 18th starting with comment: 'A patch from Pierre Smits...'

Thank you for sharing insights in how Git could work for this project. I
appreciate it.

Can you provide links to examples of an Apache project using Git that shows
a contribution from a non-privileged contributor as you describe? It would
surely help understanding the described visibility and help this community
to make a sound decision when all has been said.

Quoting:

which non-committer has submitted the most code to OFBiz and what was the
distribution of their changes amongst the various OFBiz components?

I would love to see that too. Maybe our PMC chair can clarify and comment
on that?

Please remember: if anyone feels that this discussion has reached a
saturation point (all viewpoints and concerns presented) and a sense of
consensus needs to be established, just call a vote. The outcome will
dictate the direction. To me this seems a procedural issue, not a code
change.

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

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 
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"  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 *
>>> 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 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 
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"  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 *
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 
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" 
 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 *
> 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
>
>>

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 
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" 
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 *
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 stro

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 :
> 
> "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 
> 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"  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 *
 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

Re: move to git.

2015-04-23 Thread Jacopo Cappellato

On Apr 23, 2015, at 11:42 AM, Martin Becker  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 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 
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"  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 *
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'

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 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  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" 
>> 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-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-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-25 Thread Jacopo Cappellato

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


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


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

On 22 Apr 2015, at 16:49, Adam Heath  wrote:


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

On Apr 22, 2015, at 11:41 PM, Adam Heath  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.


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" 
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-27 Thread Jacopo Cappellato

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


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 :

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.