Policy on commit

[Jacques Le Roux]

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

[Jacques Le Roux]

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

[Nicolas Malin-2]

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

[Jacques Le Roux]

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

[Kev2600]

Unsubscribe

On Thu, Aug 30, 2018 at 7:04 AM Jacques Le Roux <
[hidden email]> 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
> >>
> >>
> >
> >
>
>

[Jacques Le Roux]

Please help yourself: http://ofbiz.apache.org/mailing-lists.html

Jacques


Le 30/08/2018 à 22:24, Kev2600 a écrit :

> Unsubscribe
>
> On Thu, Aug 30, 2018 at 7:04 AM Jacques Le Roux <
> [hidden email]> 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
>>>>
>>>
>>