Thanks Nicolas,
I'll wait a bit more for opinions and if we mostly agree will being to write a
draft.
Not a hurry, but of course all opinions, and especially ideas even if in draft
form , are welcome!
Jacques
Le 30/08/2018 à 11:20, Nicolas Malin a écrit :
Hi Jacques,
I agree with the main Michael's idea and yours to load it as best practice.
Now I'm not the better man to rewrite a formulation. But if no inspiration here
I can try a first prose
Nicolas
On 27/08/2018 10:15, Jacques Le Roux wrote:
Hi Michael, All,
First, thank you Michael for your effort in trying to clarify what to discuss in dev ML (this has already been , when to revert a commit, and I'll
add relations with Jiras status.
I know it's important for you to correctly deliver the information about OFBiz
activity in the monthly blog post
My goal here is to decide if we should write best practices for that in
https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices
<https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices>
And if yes, to clearly write them. This to avoid future confusion and conflicts
in the community about these subjects.
Before beginning on that, I have already collected some information, I'd like to be sure we all agree about doing so. Then, if we agree we can
begin to discuss what to write...
Thanks for your attention
Jacques
Le 19/08/2018 à 11:28, Michael Brohl a écrit :
I have not the time to dig into the specific details right now so will just
give my thoughts on the process in general because of the citations:
1. we have to distinguish between (a) completely new functionality or major refactorings and (b) the enhancement of functionality which is already
in the code base
2. for (a), we should first have consenus that we want the proposed solution and we should look for a complete, well designed and carefully tested
solution before the first commit will be done. This is to prevent the introduction of new problematic code.
3. for (b), I think every improvement of existing code/functionality helps and should be committed if there are no flaws in the design or
technical solution and it does not break existing funtionality. of course, it should be complete within the *scope* of the improvement.
4. if the solution for (b) does not cover other wishes or things which could be enhanced also, this would be no reason to not commit the
improvement. If people have further requirements, they can provide concepts and solutions/patches anytime to make things better.
In this case, for me it is important if Suraj's commit
a. breaks anything?
b. is vetoed by other committers in view of code quality or design flaws?
If none of these questions get a "yes", then I see no reason to revert.
If you have additional requirements, you are encouraged to provide solutions or
concepts for them.
Thanks,
Michael Brohl
ecomify GmbH
www.ecomify.de
