Hello Paul, Jacopo and Olivier,
Paul Foxworthy <p...@cohsoft.com.au.INVALID> writes:
Being clearer about it would be a good thing. There is still the
potential that a change that seems simple and straightforward to one
contributor is disruptive to others. And if it truly is disruptive, we
should collaborate on what comes next. Are the benefits worth the
disruption? Should there be some sort of deprecation, phase-out or
backwards compatibility option? I can't clearly define what "big" is,
but I know it when I see it.
IMO “We Should collaborate” is wishful thinking, because in practice
what happens most of the time is that only one person is doing the work
that he/she is proposing and the rest is doing +1 or -1. When someone
objects it often just means more burden for the person doing the work
because the person objecting will just add extra requirements.
Don't get me wrong, I find that situation normal because nobody is doing
a better job than someone who is motivated about it. Moreover people
with “ideas” but which are not responsible for implementing those tend
to advocate less practicable ideas.
It is just that I don't think we should expect the community to work
collectively better than the norm by relying on collaboration to be able
to get things done.
Jacopo Cappellato <jacopo.cappell...@gmail.com> writes:
There will always be a tension between guaranteeing backward compatibility
for the existing user base and the efforts to maintain our codebase,
enhance/refactor/innovate it.
Considering the peculiar nature of OFBiz, I don't think that trying to
define the areas that are part of the "public API" and then guarantee
backward compatibility only for them, will resolve this tension. In fact
there may be cases in which the "public API" should change in a
non-backward compatible way such as:
* the cost of maintaining a backward compatible feature is too high for our
community (or there is not enough interest in the active community in
maintaining it)
* the change is required to fix a flaw or a security vulnerability
* some fundamental (and important to the community) architectural change
may not be backward compatible
* etc...
Specifying a public API does not mean necessarily preserving it. It just
mean knowing when a border is being crossed:
- The developer changing something that is part of that API
- The user using an undocumented mechanism that happen to be here.
Apart from this, even the definition of "public API" for OFBiz is
troublesome considering for example that potentially any OFBiz service can
be used by "client" code and as a consequence in theory our community
should never change the behavior (or remove) a service.
Ideally yes because the notion of services is about providing something
to others. To reduce the compatibility cost it should be possible to
make “convenience” services that are only meant to be used locally by
other services, be implemented as a private/package level helper methods
instead of a service.
I don't have specific examples in mind but I am pretty sure that there
exist a lot of those.
There are cases (like the one that triggered this conversation) that may
involve some community discussion because it is difficult to figure out if
the cost (in terms of pains for our users) is worth the gain (in terms of
better/cleaner code): sometimes these discussions can be frustrating but if
we all try to stay open (to the other point of view), positive, flexible,
patient I am sure we will cope with them.
I agree that it is normal to spend some potentially long time discussing
the tradeoffs when considering a change that impact the public API
(whether it just adds a new feature or it breaks/deprecate existing
ones)
However knowing the boundaries between the public/private API is very
useful to understand each other and agree on the extent of those
tradeoffs.
For example in the current situation it happens that Michael is
considering “applications/component-load.xml” part of the implicit
public API¹ and as a consequence requires a community validation, a
deprecation period and a migration guides to be provided. When in the
same time I am considering it as an implementation detail that don't
need such extra work on my side.
Basically listening to each other in the context of an objection to a
change means putting all the burden on the framework developper which
either have to spend time convincing users that they should not use one
thing and migrate to another thing, or adding corner cases inside the
code to preverve the specific behavior expected by users.
Moreover even if the burden is all on the developer this still sucks
because it works only for users involved in the development (subscribed
to ML), but others will have to deal with their own unexpected breakage
without having the developer to help them.
Olivier Heintz <holiv...@apache.org> writes:
4) implementation detail or core choice, often, it's depend of point
of view you use On ERP development / implementation there are multiple
type of people working on it with each one, specifics knowledge,
usage, practice and point of view. When someone says, it's a big
change, start by trusting him and find out which process is affected
to propose a solution; he doesn't want to block something, he wants to
help you come up with a better solution that solves more cases.
Given that it is very easy to get a convincing argument by saying
“people might depend on …”, I am rather skeptic.
Even if I trust others for providing valuable inputs or proposing good
ideas, I am confident that if someone happen to rely on any mechanism in
production that is considered for removal/rewrite he/she will always
choose a solution that make the person proposing the change to do
whatever is necessary to not require them to do a migration work.
Again I am not saying that this is wrong, I am just saying that this
natural force should be balanced with something assessing that only a
subset of all mechanisms are subjects to such argument and using the
complement of that subset mean that users are on their own and they
should be prepared for breaking changes.
6) what is OFBiz,
- not only a public API ;-)
- not only a framework
- currently not a OOTB ERP but I hope what, in future, there will contain
some OOTB applications
In my long term view Apache OFBiz could be like linux, a core/kernel as small
as possible with multiple components (the plugins) and so with some
distributions.
So, clearly, for me it is not possible to define the boundary between what is
public (with backward compatibility) and what is only implementation.
Even on data model I can give some examples where not everyone will agree on
what is in kernel and what is in components
I believe that any effort of modularizing the code base without relying
on a stable public API like moving plugins inside independent
repositories is doomed. I am personnally still not convince that seeking
for dozens of custom plugins is a good idea even with a stable public
API.
Regarding the core + plugins ideal, it is interesting that you brought
the linux kernel example because it is the perfect example of a
monolithic development process where every driver/module (plugin) that
seeks for backward compatibility must be maintained inside the main
repository because there is no guarantee on the interface between the
core and the plugins. A week ago, here is what Linus Torvalds was saying
to people considering developing a module for ZFS (a file system)
outside of the main repository [1].
I am curious about the data model example you have in mind?
[1] https://www.realworldtech.com/forum/?threadid=189711&curpostid=189841
¹ The question about “plugins/component-load.xml” is different because
there is a consensus on the fact that is part of public API however I
have the impression that it is still in alpha state given that plugins
mechanism is relatively new.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
