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
