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 <sharan.f...@gmail.com> het
volgende geschreven:
Hi All
I've been looking at some of what OFBiz France has done regarding addons
for OFBiz . I think there are a lot of useful things that have been
contributed by the community in general (not only OFBiz France) that are
either sitting in forks or addons or just in Jira that haven't really been
visible to the community.
Making them visible gives the community more freedom and choice - whatever
tool is used.
Thanks
Sharan
On 21.4.2015 12:19, Jacques Le Roux wrote:
Le 21/04/2015 12:02, David E. Jones a écrit :
On 20 Apr 2015, at 23:21, Pierre Smits <pierre.sm...@gmail.com> wrote:
Quoting:
We are also prepared to be assertive regarding this situation. If the
project
does not move to GIT then Brainfood is willing to participate in a
consortium of
organizations that will peer with each other to share updates to the
master
branch for their local OFBiz repository. Such an arrangement will,
effectively,
result in a distributed master repository image.
Thanks Ean for the position of *Brainfood* in this position. It comes
across as 'Do it our way, or else'. You are free to make such statements
and when followed through there will be consequences. For all
participating
in this project. One I can see standing out clearly is: no more
participation in/contribution from the employees of Brainfood and from
the
other companies in that consortium back into the project.
That's not at all what I get from Ean's comments. The magic of a
community-driven project is that people can collaborate on anything they
want, within the scope of the main project or as side projects. If the main
project doesn't provide something desired, then it is perfectly appropriate
for others to collaborate on that... better than doing it totally isolated.
What Ean is talking about ties in with the general idea of distributed
source management and distributed development. The general idea is that
there may be many forks of the main source repo, potentially with various
branches for different improvements and changes. These are generally made
available publicly, like public GitHub forks of other public repositories
(though with git they can be hosted anywhere).
Those who make changes can request that particular changes be pulled
into upstream repositories and then those who maintain the upstream repos
(or the main project repo if it bubbles up that high) can review them and
pull the changes if desired. Those who maintain upstream repos can also
look around for useful changes in forked repos and pull them in as desired.
Others who run their own forks can pull in changes from peer repositories
too.
It may seem like chaos to have forks and changes spread all over the
place... but that isn't caused by the distributed source management
approach, it's just made visible and clear by the approach. Right now this
exists on a large scale for OFBiz, tons of forks and changes in them, but
they are mostly not visible or publicly available so there is no way for
OFBiz committers to pull changes from other repos... they basically have to
be extracted into a patch file and submitted through a Jira issue.
In other words, the chaos exists and the distributed source management
enabled by git just makes it easier to track it all and tame it a bit.
On a side note, this is one of the reasons I have concerns about making
Moqui and related projects part of the ASF: the ASF community approach
doesn't fit very well with this distributed source management model (pull
requests are discouraged, all contributions should go through Jira
issues... though I don't know that this is a strict policy).
-David
Interesting David, it can be compared to the OFBiz-France association
effort to leverage the Nereides addons and addons manager. I let aside the
licenses issues, as long as it's no part of a released package there are no
problems.
What do you think OFBiz-France members?
Jacques
If that is going to happen, I will say: 'I thank you for all the
contributions you did to the project'. And I will check in my
sentiments at
the door. I do hope that if you do you also resign totally from this
project.
I rather have the community comes to its decision based on sound/valid
arguments, not (veiled) threats.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler <e...@brainfood.com>
wrote:
----- Original Message -----
From: "Jacques Le Roux" <jacques.le.r...@les7arts.com>
Subject: Re: move to git.
Like Adrian and mostly for the same reasons, I don't believe we need
Git.
But there is one other major reason which has already been discussed
in
the
other common ASF MLs. As Taher exulted, it's possible to create local
branches. So people are able to do a lot of work alone without
exchanging before
committing or submitting. It will certainly not help to have this
possibility.
I disagree. It is useful in many situations for OFBiz developers to
create
a
local repository that is not globally shared. Some customers may even
require
such a situation for security or legal reasons.
Remember our recent discussion on the lack or core commits reviews.
With Git you end with commits bursts or big patches and it's then
hard to review and too late to share ideas.
So unlike Adrian, I'm even strongly against it. I will not hesitate to
use a -1
if necessary!
We are also prepared to be assertive regarding this situation. If the
project
does not move to GIT then Brainfood is willing to participate in a
consortium of
organizations that will peer with each other to share updates to the
master
branch for their local OFBiz repository. Such an arrangement will,
effectively,
result in a distributed master repository image.
If anyone else is interested in such an arrangement please feel free to
speak
up and we can begin the planning process.
