Hi Mathieu,I'm not sure if we understand each other correctly and maybe talk at cross-puposes.
Hope you are open to read my comments inline... Am 05.02.20 um 15:34 schrieb Mathieu Lirzin:
Hello, Michael Brohl <michael.br...@ecomify.de> writes:Am 31.01.20 um 13:15 schrieb Jacques Le Roux:We could continue the discussion in this thread or at https://issues.apache.org/jira/browse/OFBIZ-11296This issue shows exactly the same pattern in the process like the component-load approach. The Jira was created and *on the same day* the first patches were committed without further discussion within the Jira. The Jiras contains a link to a discussion with the statement "this has been discusses on Development mailing list". In fact, the thread also started on the same day in dev but has not many reactions and in no way any decision to go in that direction. This is by no means the correct way to introduce fundamental changes to the project.This description is dishonest, I have always opened discussions on this mailing-list and waited for feedback when considering a *big/breaking change*. I have only moved fast when I considered that what I was working on was an implementation detail and that the improvement was obvious.
My latest emails were not adressed at the depends-on topic but the changes proposed in [1]. See below also.
The actual issue is not that I did not follow the rules. The fact that I ended up opening/closing a JIRA the same day I commit things that I consider trivial was precisely to conform to the policy of “every change needs to have a JIRA associated” which is bureaucratic non-sense.
I think it helps to keep track of the many issues we have to work on.A good example is my own fault to not create a Jira for [3]: I fixed a bug but forgot to backport.
If I had created a Jira, other might have spotted it and reacted or I may have thought about backporting myself. It was sheer luck that I stumbled upon it again.
As much as I appreciate the initiative to move things forward I am also strictly against the approach and process to put fundamental changes into the codebase without through conceptual work and planning.I am glad that you appreciate the initiative, but as far as I am concerned I am certainly not enjoying my time in this community anymore.
For which I feel truly sorry and I apologize if I caused frustration and did not find the right words to express my concerns in a more motivating way.
https://issues.apache.org/jira/browse/OFBIZ-11161 is also related Maybe better to create a new thread?We already have a thread for it, started on 22. August 2019. I would very much appreciate if experienced users/developers would join this discussion (which I have missed being on vacation at the time and, having not much response, did not get my attention until now).Basically you are acknowledging that nobody cares deeply about the idea I proposed in previous thread (which is probably true) but at the same
I did not say that nobody cares, I said that the thread does not get many responses. The reasons can be manifold.
The reason why *I* have not responded is that I was on vacation and had an immense workload of projects until the end of the year afterwards. I was more or less off as you can see at my engagement in the dev list after June.
Others may have had same issues. Sometimes a topic needs patience or reminders for the community to pick up.
I care a lot for this topic, which is why I expressed my wish to the community to join the discussion on several occasions. We simply have different perspectives, which is good IMO. Together with more perspectives from others, we will be able to build a clearer picture of the vision and an actionable plan to reach its realization.
And I really think that a more detailed roadmap will help to engage more people in the collaboration (which would be more fun also).
time you are suggesting me to write a lengthy design/architectural document that will rephrase what as already been said in that thread.
I have suggested to write down and discuss important details and the pros/cons of different approaches and ideas. IMO it's the only way to engage the community in actionable work items and collaboration. It does not necessarily mean that it needs lengthy documents. A simple Wiki page would do for a start.
Sorry but no, I will not write such document, I have already explained multiple times the design principles leading to the proposal of enabling the distribution of OFBiz inside a Jar: - Extensible dependency management is better than having to define a arbitrary global ordering - Location independent loading/configuration mechanism is the only sane way to provide true extensibility. - Adopting the stable mechanism provided by the Java platform that we already depend on is better than implementing our own specific mechanism If people are not convinced by the benefits of this vision which imply deprecating the “component-load.xml” mechanism and use “depends-on” instead (which I did not introduced in the first place) then providing a precise design/implementation plan will not help moving forward, it will just lead to more time waste on my side.
I think depends-on is a point we already have discussed and this was not my topic in the latest emails. My proposal to write up a concept is adressed to the "big picture" you have described in [1], which contains your statement:
"Here is a *big* change that I am considering for OFBiz to fixes those issues by leveraging the Java platform which already provides everything that we need to fix those issues: ..."
I was talking about this big change and the plan behind it. In the initial discussion you gave a brief vision, which should be worked out by the community to move forward. A vision is far from a concept the community can decide on, which is my main point I expressed earlier.
[2] is the Jira with first changes and commits regarding the big picture, which is why I intervened to hold on and talk about the concept before changing things in *trunk*.
I don't see the point of continuing this unproductive discussion neither to proceed with a formal vote regarding the deprecation of “component-load.xml”, because whatever the result I have lost my faith in the capability of this community to succeed at handling the technical challenges that will enable OFBiz to stay relevant in the future. But this is fine.
As I've sorted out the "depends-on" topic as the reason for the wish for a concept/plan: do you also think that a discussion about the *big change* is unproductive and is not necessary?
How do you do conceptual work with clients or colleagues? I believe there is some kind of written documentation and clear decision points involved at least for non trivial features/changes.
I sincerely hope that we can sort out the resentments and find a way to collaborate on the challenges that lay ahead.
Best regards, Michael [1] https://s.apache.org/7e590 [2] https://issues.apache.org/jira/browse/OFBIZ-11161[3] https://lists.apache.org/thread.html/re7d18081eea709568ad6b1076dcd7464fe750107e222dada0b4994a2%40%3Cdev.ofbiz.apache.org%3E
smime.p7s
Description: S/MIME Cryptographic Signature
