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
