Re: Policy on commit

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

Re: Policy on commit

[Kev2600]

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

Re: Policy on commit

[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



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

Re: Policy on commit

[Nicolas Malin]

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
 



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

Re: Policy on commit

[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



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