Hello Mathieu and all, Thank you for this interesting and engaging thread. Before I make my input, I would like to note that Apache OFBiz and its community from my experience is welcoming of change and improvements. In my earlier days in the project we went through massive changes to the system that made tremendous differences including:
- Moving from ant to gradle - introducing unit tests - Redesigning the startup logic and possible flags - Changing the distribution mechanism (remote dependencies instead of inside the code base) - Changing folder structures in components - many others 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. 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. My 2 cents Cheers, Taher Alkhateeb On Sun, Jan 12, 2020 at 4:56 AM Mathieu Lirzin <mathieu.lir...@nereide.fr> wrote: > > 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
