ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacques Le Roux <jacques.le.r...@les7arts.com>
Subject Re: Policy on commit
Date Wed, 29 Aug 2018 09:53:55 GMT
oOps, I missed to finish a sentence... amended inline...


Le 27/08/2018 à 10:15, Jacques Le Roux a écrit :
> 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.
(this has already been discussed and agreed in the past)

> 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
>
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message