Unsubscribe On Thu, Aug 30, 2018 at 7:04 AM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote:
> 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 > >> > >> > > > > > >
