HI Piere, inline...
Am 21.01.20 um 15:56 schrieb 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.)
Agreed and in no way questioned in the preceding discussions.
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.
Of course we are not held responsible in a legal sense. But we (should) feel responsibility towards the users of the project and maintain it in a way which is in good balance between the user base needs and the contributions made to improve it.
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.
Where do I find this anywhere in the statutes of the project?I strongly disagree with this statement. If we propagate that we don't care about the users and change the codebase, functionality and mechanisms without thinking about backwards compatibility, breaking existing projects and even don't support users with the documentation of a migration path, we will damage the projects' reputation.
This is not a playground project, it is used in serious businesses and we should have this in mind when changing things.
This is my main concern with the approach leading to the preceding discussion.
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.
Can you please point us to the source of these claims?
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.
This seems to be very speculative to me. Where does the information for this claim come from?
The trunk is the source for the next stable branch and every change made there will sooner or later be in a next release and will have effects on users who will use it.
As a responsible developer, changes made to the codebase, especially if they are made to support a future change/improvement/refactoring, should be well planned, discussion, proved if they are really wanted/needed etc.
Another problem is that trunk receives a mix of functionality enhancements and improvements for the business part and also core improvements which might need a long time to be implemented (an example might be the initiative to make the framework container independent).
If we want to have shorter release cycles to bring the functionality updates to the users, this is in conflict with the improvements which needs more time to be implemented and thorougly tested. This is the reason why I would prefer to do these implementations in a feature branch which will be held up-to-date with trunk and allows experimental implementations without breaking anything. This is the classical and logical way when maintaining a product.
If you would see the project as a software development company which sells a product, this company would never start long-lasting developments in the base branch for the next release.
Release management and a clear roadmap would help, maybe a dicussion for another thread.
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).
In this case, there seem to be plans in the minds of contributors which lead to the discussed changes. These plans are neither documented nor discussed in depth so that it is possible to make decisions. This is my main concern.
I also gave several arguments why it breaks existing functionality/configuration options when it is introduced in full (which means also being introduced in applications and plugins).
I'm fine with the introduction in framework, even if I don't see why it should be regarded as a big improvement. It will manage the dependencies of 4 component folders in framework which will not change and have a clear loading order.
In general, I definelety appreciate these initiatives but mainly question the process/approach to introduce them. We already have unfinished code/functionality in the project which is the result of this approach. I simply want to avoid this.
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.
It did not break the code but break the functionality which was present with the component-load mechanism.
I think also made clear that I do not object a commit for the framework part (excluding applications).
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.
Strong words and not even near to reality in my view.Discussions being made to find the optimal approach/solution for a problem are the core principal of community projects and they are needed as we can see in many examples. And they always lead to better solutions as if a single person would do them alone. A principle which is also true for works withing teams of a company.
These discussions might be unconfortable for someone and make developments slower, but I'm sure that they will be valuable and lead to better results.
What I really miss is more people and especially committers to engage in these discussions because I think they should be important to more than a handfull of community members.
Thanks, Michael
Best regards, Pierre Smits
smime.p7s
Description: S/MIME Cryptographic Signature
