Re: What is OFBiz public API?

[Jacques Le Roux]

Thanks Pierre,

I second that, I would not write it better!

Jacques

Le 21/01/2020 à 15:56, Pierre Smits a écrit :

Hi all,

The mission of the project is, in line with the ASF, to provide software
for the greater good and offering (potential) adopters a choice. In the
projects case this is done through providing the OFBiz works (each and all
products, as well as the supporting tooling for enabling contributors like
JIRA, Github services, etc.)

The project has since its inception as a TLP made it clear, with the above
in mind, that the the project is not responsible for the choices a
(potential) adopter has made, nor that it will be held responsible for the
future choices of an adopter.
This means, when talking about the code of the main OFBiz product, the
project does not care whether an adopter (being it either an enterprise
having OFBiz implemented, or a service integrator offering services and/or
solutions for payment or not) uses, enhances or diminishes the OFBiz
functionalities in upstream activities.

The project has also made clear in communications to every kind of
community member and adopter, that for use, enhancement or diminishment of
OFBiz functionalities in his environment of development and service
delivery the adopter should always start from releases and not from the
volatile trunk repositories.
Unfortunately, there have been (and are) several prominent members of the
OFBiz community that have made assertions that it was quite ok for adopters
to start with the code in the trunk branch of the repo for their own
develop and/or implementation.
When these community members propagate this start-with-trunk paradigm in
their upstream needs-and-wants model, they tend to shoot in their own foot.
But instead of acknowledging that they took a wrong turn and remediate that
situation, they elect to bring their problem down to the OFBiz project and
demand that the other contributor removes this undesirable change from the
OFBiz code base, in order to keep the upstream deviation minimally
disrupted.

Given what Mathieu has brought forward regarding the 'depends-on'
enhancement of the OFBiz functionality, it is clear that it strengthens and
enhances understandings regarding the OFBiz product and its intricacies
(where the code is the documentation).

When looking at the process undertaken by Mathieu, he was working within
his mandate as a community member with the commit-privilege to commit the
changes to the trunk branch of the repo (as per ticket OFBIZ-11296, commit
  eeabe69813a1d9f42911dec70a912574046ef49b). Moreover, he was also working
along and in-line with precedents established by other community members
before he became a privileged contributor.

The discussion that later developed was a good thing, but with precedents
as they are it is unfortunate that the commit was later reverted.
Unfortunate, not because the discussion developed but because the commit
did not 'break the code'. Precedents have shown that questionable commits
did not lead to reversal of these commits.

If, and when, all understand the rules of engagement of the OFBiz project,
and act accordingly, there would never by such a (heated) discussion as
this one, or the ones leading up to this (whether started and followed
through in JIRA tickets, or on any of the mailing lists). Apparently many
of the community members (including those with privileges) do not
understand what these are or these provide to ambiguity which leads to
deviations when contributing.

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer

Call for presentations for ApacheCon North America 2020 now open

[Rich Bowen]

Dear Apache enthusiast,

(You’re receiving this message because you are subscribed to one or more 
project mailing lists at the Apache Software Foundation.)


The call for presentations for ApacheCon North America 2020 is now open 
at https://apachecon.com/acna2020/cfp


ApacheCon will be held at the Sheraton, New Orleans, September 28th 
through October 2nd, 2020.


As in past years, ApacheCon will feature tracks focusing on the various 
technologies within the Apache ecosystem, and so the call for 
presentations will ask you to select one of those tracks, or “General” 
if the content falls outside of one of our already-organized tracks. 
These tracks are:


Karaf
Internet of Things
Fineract
Community
Content Delivery
Solr/Lucene (Search)
Gobblin/Big Data Integration
Ignite
Observability
Cloudstack
Geospatial
Graph
Camel/Integration
Flagon
Tomcat
Cassandra
Groovy
Web/httpd
General/Other

The CFP will close Friday, May 1, 2020 8:00 AM (America/New_York time).

Submit early, submit often, at https://apachecon.com/acna2020/cfp

Rich, for the ApacheCon Planners

Re: What is OFBiz public API?

[Pierre Smits]

Hi all,

The mission of the project is, in line with the ASF, to provide software
for the greater good and offering (potential) adopters a choice. In the
projects case this is done through providing the OFBiz works (each and all
products, as well as the supporting tooling for enabling contributors like
JIRA, Github services, etc.)

The project has since its inception as a TLP made it clear, with the above
in mind, that the the project is not responsible for the choices a
(potential) adopter has made, nor that it will be held responsible for the
future choices of an adopter.
This means, when talking about the code of the main OFBiz product, the
project does not care whether an adopter (being it either an enterprise
having OFBiz implemented, or a service integrator offering services and/or
solutions for payment or not) uses, enhances or diminishes the OFBiz
functionalities in upstream activities.

The project has also made clear in communications to every kind of
community member and adopter, that for use, enhancement or diminishment of
OFBiz functionalities in his environment of development and service
delivery the adopter should always start from releases and not from the
volatile trunk repositories.
Unfortunately, there have been (and are) several prominent members of the
OFBiz community that have made assertions that it was quite ok for adopters
to start with the code in the trunk branch of the repo for their own
develop and/or implementation.
When these community members propagate this start-with-trunk paradigm in
their upstream needs-and-wants model, they tend to shoot in their own foot.
But instead of acknowledging that they took a wrong turn and remediate that
situation, they elect to bring their problem down to the OFBiz project and
demand that the other contributor removes this undesirable change from the
OFBiz code base, in order to keep the upstream deviation minimally
disrupted.

Given what Mathieu has brought forward regarding the 'depends-on'
enhancement of the OFBiz functionality, it is clear that it strengthens and
enhances understandings regarding the OFBiz product and its intricacies
(where the code is the documentation).

When looking at the process undertaken by Mathieu, he was working within
his mandate as a community member with the commit-privilege to commit the
changes to the trunk branch of the repo (as per ticket OFBIZ-11296, commit
 eeabe69813a1d9f42911dec70a912574046ef49b). Moreover, he was also working
along and in-line with precedents established by other community members
before he became a privileged contributor.

The discussion that later developed was a good thing, but with precedents
as they are it is unfortunate that the commit was later reverted.
Unfortunate, not because the discussion developed but because the commit
did not 'break the code'. Precedents have shown that questionable commits
did not lead to reversal of these commits.

If, and when, all understand the rules of engagement of the OFBiz project,
and act accordingly, there would never by such a (heated) discussion as
this one, or the ones leading up to this (whether started and followed
through in JIRA tickets, or on any of the mailing lists). Apparently many
of the community members (including those with privileges) do not
understand what these are or these provide to ambiguity which leads to
deviations when contributing.

Best regards,

Pierre Smits

*Apache Trafodion , Vice President*
*Apache Directory , PMC Member*
Apache Incubator , committer
*Apache OFBiz , contributor (without privileges)
since 2008*
Apache Steve , committer

Re: What is OFBiz public API?

[Jacques Le Roux]

Le 21/01/2020 à 00:36, Mathieu Lirzin a écrit :

Hello,

Taher Alkhateeb  writes:


While working on all the above, I never faced major obstacles. But the
reason that I did not is I always made a complete, well written
argument about what I'm trying to implement. I always ask for a pair
of eyes to look at my code and give me feedback, and I always engage
with the community. In my opinion, disagreements made me do some of
the best pieces of code because I learn and grow from other people's
input.

That sounds a lot like a polite way to suggest that I did not engage
properly with the community. I have done my best to get people involved
while acknowledging the need to move relatively fast which IMO is
justified by the abyssal technical debt of OFBiz.


The boundary of a public API does not necessarily need to be agreed
upon RIGHT NOW!. I don't think the best way to move forward is to
enforce agreeing on what we should done before hand.

Instead of setting rules and boundaries on what should and should not
be done, I recommend instead collaborating on all work, one piece at a
time. As I said, I've worked on very large issues indeed and had no
problem working it with others and making it eventually to the code
base.

So whenever there is a disagreement or differing points of view, why
not start a new thread specific to that topic and work it out.
Everybody wants the best for the project, and communication is the key
to moving us forward IMHO.

I agree that communication is important as long as it enables people to
move forward, currently we are blocked.  If you look at the initial
discussion, you will see that this is precisely a deadlock in a *thread
specific* conversation between Michael and me that lead to this general
question.

This specific discussion is simply unsolvable because everybody is
basing their arguments on undocumented assumptions regarding what needs
to be preserved, what needs to be superseded, how things are supposed to
be done, etc.  This is basically a sterile “you broke my business
specific extension” vs “I want to improve the framework” debate where
both perspective can be seen as legitimate but are fundamentally
incompatible with each other in practice.

To recap the discussion, it appears that most people that have responded
to my call for defining/documenting what is part of OFBiz public API
feel this would be an unnecessary and counter-productive action and that
case by case discussions can be a more valuable substitute.

As a consequence I think we can close the subject now.

Thanks to everyone who took some of their time to participate.


Hi Mathieu,

Sorry I disagree, I for one would very like to have what you expressed at 
https://s.apache.org/5gryr in OFBiz in future

We can agree to disagree with Michael, and have it in trunk. As I said already, 
it would let several years for users (like Michael) to adjust.

Of course for that we need a vote and Michael not to veto this change on trunk 
with solid arguments.

Else, seeing yours and Samuel's recent framework efforts compared to the rest of the community, I fear the future of OFBiz is not bright. Apart if we 
consider the UI as the most important, which I don't...


I'm ready to engage a vote if you agree with me

Thanks

Jacques