Yeah Jacques, i got your point, but clarification was needed to avoid
the assimilation of Nereide and OFBiz-France association (no lobbying or
so).
Clearly if Git is adopted (even if not I guess, there is a workaround)
there will be a new way to share/maintain solution around OFBiz.
Like i said i didn't had the time to learn more about git, but from what
i read in the thread, it could be a good tool.
Gil
On 29/04/2015 14:47, Jacques Le Roux wrote:
Thanks for taking the time to clarify Gil, I was in a hurry and did
not put enough information, let me clarify my point.
I only wanted to speak about the tool used to create, maintain and
share extensions. For the moment the "OFBiz-France solution" (actually
more Nereides one) is based on the patch command and the addons manager.
The idea here was, if ever the OFBiz project would use Git instead of
Svn, maybe the OFBiz-France solution could be based on Github and
maintained as described below by David. Still a lot of of
speculations, but better to think ahead even if nothing happens ;)
Jacques
Le 21/04/2015 15:09, Gil portenseigne a écrit :
Hi all,
First to clarify things, OFBiz-france association goal is to promote
Apache OFBiz into french speaking audience by giving references
(information, classifications and links) to extensions
(documentations, addons, patchs or packaged solution), maybe hosting
some high quality not contributable extensions.
Helping extensions' owner improving their quality to convert its into
OFBiz contribution if possible, or referencing them for easy sharing
of classified solutions.
Creating a tool integrated into Apache OFBiz too manage and share
anyone devs by implementing a new extension manager
(http://ofbiz.markmail.org/message/goxbqcgurpoy2yfp?q=ofbiz-fr
without success for now :) )
Nereide Leverage of addon solutions, like you introduce is just an
illustration of this process. Nereide as a member of the association
will give as example some instance of extensions, hoping that other
contribution and contributor will come (and be welcome).
I think that this git solution of *creating a consortium [...]* is
quite different (even if i do not understand all the ins and out of
it) and might be more comparable to ofbizextra effort, to give the
ability for everyone to develop and share using a dedicated tool.
And because everything which is committed into Apache OFBiz project
has to be validated, and development within Integrators Projects do
not have the same rythm/pace, ofbizextra was created to store and
share unfinished/specific/not ready quality wise devs and this has to
be out of Apache OFBiz.
My personal opinion is (i'm not a git user), that SVN seems quite
sufficient for Apache OFBiz needs. I remind me reading that there is
already a git repository of the trunk branch so, if true, it can be
used by contributor too make their devs using it. I'm not relevent
evaluating git usage, but i do not feel a real problem using SVN.
In every case, contribution will have to be given within Jira to get
into the project.
Best Regards
Gil
On 21/04/2015 12:19, Jacques Le Roux wrote:
Le 21/04/2015 12:02, David E. Jones a écrit :
On 20 Apr 2015, at 23:21, Pierre Smits <pierre.sm...@gmail.com>
wrote:
Quoting:
We are also prepared to be assertive regarding this situation. If the
project
does not move to GIT then Brainfood is willing to participate in a
consortium of
organizations that will peer with each other to share updates to
the master
branch for their local OFBiz repository. Such an arrangement will,
effectively,
result in a distributed master repository image.
Thanks Ean for the position of *Brainfood* in this position. It comes
across as 'Do it our way, or else'. You are free to make such
statements
and when followed through there will be consequences. For all
participating
in this project. One I can see standing out clearly is: no more
participation in/contribution from the employees of Brainfood and
from the
other companies in that consortium back into the project.
That's not at all what I get from Ean's comments. The magic of a
community-driven project is that people can collaborate on anything
they want, within the scope of the main project or as side
projects. If the main project doesn't provide something desired,
then it is perfectly appropriate for others to collaborate on
that... better than doing it totally isolated.
What Ean is talking about ties in with the general idea of
distributed source management and distributed development. The
general idea is that there may be many forks of the main source
repo, potentially with various branches for different improvements
and changes. These are generally made available publicly, like
public GitHub forks of other public repositories (though with git
they can be hosted anywhere).
Those who make changes can request that particular changes be
pulled into upstream repositories and then those who maintain the
upstream repos (or the main project repo if it bubbles up that
high) can review them and pull the changes if desired. Those who
maintain upstream repos can also look around for useful changes in
forked repos and pull them in as desired. Others who run their own
forks can pull in changes from peer repositories too.
It may seem like chaos to have forks and changes spread all over
the place... but that isn't caused by the distributed source
management approach, it's just made visible and clear by the
approach. Right now this exists on a large scale for OFBiz, tons of
forks and changes in them, but they are mostly not visible or
publicly available so there is no way for OFBiz committers to pull
changes from other repos... they basically have to be extracted
into a patch file and submitted through a Jira issue.
In other words, the chaos exists and the distributed source
management enabled by git just makes it easier to track it all and
tame it a bit.
On a side note, this is one of the reasons I have concerns about
making Moqui and related projects part of the ASF: the ASF
community approach doesn't fit very well with this distributed
source management model (pull requests are discouraged, all
contributions should go through Jira issues... though I don't know
that this is a strict policy).
-David
Interesting David, it can be compared to the OFBiz-France
association effort to leverage the Nereides addons and addons
manager. I let aside the licenses issues, as long as it's no part of
a released package there are no problems.
What do you think OFBiz-France members?
Jacques
If that is going to happen, I will say: 'I thank you for all the
contributions you did to the project'. And I will check in my
sentiments at
the door. I do hope that if you do you also resign totally from this
project.
I rather have the community comes to its decision based on
sound/valid
arguments, not (veiled) threats.
l
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Tue, Apr 21, 2015 at 2:08 AM, Ean Schuessler
<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.
