Re: svn commit: r1855798 - /ofbiz/ofbiz-framework/trunk/build.gradle

[Michael Brohl-3]

Hi Mathieu,

don't we have Jira's for all these changes?

If yes, please provide the issue number within the commit message so
that we have them in the monthly blog post/dev details.

If no, we should have them, at least in the future.

If these changes affect the documentation, the README.md should also be
edited to reflect them and stay in sync with the code.

Thanks for your work!

Michael

Am 19.03.19 um 00:19 schrieb [hidden email]:

> Author: mthl
> Date: Mon Mar 18 23:19:44 2019
> New Revision: 1855798
>
> URL: http://svn.apache.org/viewvc?rev=1855798&view=rev
> Log:
> Improved: Merge regexps inside ‘createOfbizCommandTask’
>
> Modified:
>      ofbiz/ofbiz-framework/trunk/build.gradle
>
> Modified: ofbiz/ofbiz-framework/trunk/build.gradle
> URL: http://svn.apache.org/viewvc/ofbiz/ofbiz-framework/trunk/build.gradle?rev=1855798&r1=1855797&r2=1855798&view=diff
> ==============================================================================
> --- ofbiz/ofbiz-framework/trunk/build.gradle (original)
> +++ ofbiz/ofbiz-framework/trunk/build.gradle Mon Mar 18 23:19:44 2019
> @@ -984,9 +984,7 @@ def createOfbizCommandTask(taskName, arg
>           classpath = files(jar.outputs)
>           main = ofbizMainClass
>           args arguments
> -
> -        if (taskName ==~ /^ofbiz.*--test.*/
> -            || taskName ==~ /^ofbiz.*-t.*/) {
> +        if (taskName ==~ /^ofbiz.*(--test|-t).*/) {
>               finalizedBy(createTestReports)
>           }
>       }
>
>

[mthl]

Hello Michael,

Michael Brohl <[hidden email]> writes:

> don't we have Jira's for all these changes?
>
> If yes, please provide the issue number within the commit message so
> that we have them in the monthly blog post/dev details.
>
> If no, we should have them, at least in the future.

Sorry if the process I followed was not the right one.

I must confess that the policy regarding how refactoring (done by
committers) must be handled in term of JIRA creation, is not clear to
me.  The block “When to create a Jira issue” on OFBiz wiki [1] is not
helping much in that regard.  Maybe there is an implicit consensus in
that regard that I am not aware of?

My reasoning for not creating a JIRA was that those commits are pure
refactoring meaning they are implementation details that don't change
the observable behavior of the build and they are not part of a global
plan.  Basically those cleanups happened by looking around while working
on OFBIZ-10866 [2] but are unrelated to the endeavour of that task.

What would you recommend in that scenario?

> If these changes affect the documentation, the README.md should also
> be edited to reflect them and stay in sync with the code.

Sure I agree that's an important guideline to follow.

Thanks.

[1] https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices
[2] https://issues.apache.org/jira/browse/OFBIZ-10866

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

[mthl]

Hello,

In the same spirit, I want to know if it is OK to improve or add some
Javadoc without opening a ticket on JIRA?

Thanks.

Mathieu Lirzin <[hidden email]> writes:

> Hello Michael,
>
> Michael Brohl <[hidden email]> writes:
>
>> don't we have Jira's for all these changes?
>>
>> If yes, please provide the issue number within the commit message so
>> that we have them in the monthly blog post/dev details.
>>
>> If no, we should have them, at least in the future.
>
> Sorry if the process I followed was not the right one.
>
> I must confess that the policy regarding how refactoring (done by
> committers) must be handled in term of JIRA creation, is not clear to
> me.  The block “When to create a Jira issue” on OFBiz wiki [1] is not
> helping much in that regard.  Maybe there is an implicit consensus in
> that regard that I am not aware of?
>
> My reasoning for not creating a JIRA was that those commits are pure
> refactoring meaning they are implementation details that don't change
> the observable behavior of the build and they are not part of a global
> plan.  Basically those cleanups happened by looking around while working
> on OFBIZ-10866 [2] but are unrelated to the endeavour of that task.
>
> What would you recommend in that scenario?
>
>> If these changes affect the documentation, the README.md should also
>> be edited to reflect them and stay in sync with the code.
>
> Sure I agree that's an important guideline to follow.
>
> Thanks.
>
> [1] https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices
> [2] https://issues.apache.org/jira/browse/OFBIZ-10866

--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

[Jacques Le Roux]

Hi Mathieu,

Le 20/03/2019 à 22:19, Mathieu Lirzin a écrit :

> I must confess that the policy regarding how refactoring (done by
> committers) must be handled in term of JIRA creation, is not clear to
> me.  The block “When to create a Jira issue” on OFBiz wiki [1] is not
> helping much in that regard.  Maybe there is an implicit consensus in
> that regard that I am not aware of?
>
> My reasoning for not creating a JIRA was that those commits are pure
> refactoring meaning they are implementation details that don't change
> the observable behavior of the build and they are not part of a global
> plan.  Basically those cleanups happened by looking around while working
> on OFBIZ-10866 [2] but are unrelated to the endeavour of that task.
>
> What would you recommend in that scenario?

I don't remember that we discussed specifically about Jira and refactoring (with no functional changes, which is the implicit definition of
refactoring). At least we did not write about it.

One thing I do for very simple no functional changes (not only for refactoring) is to use this syntax in commits comments :

    Improved: no functional change

    Explanations...

When the changes are considerable (which is subjective, it's hard to set a line) I create a Jira and explain the changes.

We could write something about that in the wiki section “When to create a Jira issue” which is quite old and has not been reviewed for a long time.
Rest that it will always be subjective, we can say that.

The same idea applies to Javadoc changes: big one a Jira, simple one no Jira.

It's a matter of judgement, when it take much more time to create a Jira than to only explain in a commit comment for instance.

The changes you did (from r1855674 to r1855798) did not hurt me. I just reviewed again and for me none of them need more explanations than in the
commits.

Now, the fact that there was 9 commits in a row could be interpreted as a substantial change and maybe explains Michael's perspective.
Then maybe a Jira referring to these commits with a summary in description could help reassuring users about these changes. Both (Jira or not) fits
with me in this case.

My 2cts

Jacques

[Jacques Le Roux]

Ah forgot we have that pending also: https://cwiki.apache.org/confluence/display/OFBIZ/Guidelines+For+Using+JIRA

Le 23/03/2019 à 11:59, Jacques Le Roux a écrit :

> Hi Mathieu,
>
> Le 20/03/2019 à 22:19, Mathieu Lirzin a écrit :
>> I must confess that the policy regarding how refactoring (done by
>> committers) must be handled in term of JIRA creation, is not clear to
>> me.  The block “When to create a Jira issue” on OFBiz wiki [1] is not
>> helping much in that regard.  Maybe there is an implicit consensus in
>> that regard that I am not aware of?
>>
>> My reasoning for not creating a JIRA was that those commits are pure
>> refactoring meaning they are implementation details that don't change
>> the observable behavior of the build and they are not part of a global
>> plan.  Basically those cleanups happened by looking around while working
>> on OFBIZ-10866 [2] but are unrelated to the endeavour of that task.
>>
>> What would you recommend in that scenario?
> I don't remember that we discussed specifically about Jira and refactoring (with no functional changes, which is the implicit definition of
> refactoring). At least we did not write about it.
>
> One thing I do for very simple no functional changes (not only for refactoring) is to use this syntax in commits comments :
>
>    Improved: no functional change
>
>    Explanations...
>
> When the changes are considerable (which is subjective, it's hard to set a line) I create a Jira and explain the changes.
>
> We could write something about that in the wiki section “When to create a Jira issue” which is quite old and has not been reviewed for a long time.
> Rest that it will always be subjective, we can say that.
>
> The same idea applies to Javadoc changes: big one a Jira, simple one no Jira.
>
> It's a matter of judgement, when it take much more time to create a Jira than to only explain in a commit comment for instance.
>
> The changes you did (from r1855674 to r1855798) did not hurt me. I just reviewed again and for me none of them need more explanations than in the
> commits.
>
> Now, the fact that there was 9 commits in a row could be interpreted as a substantial change and maybe explains Michael's perspective.
> Then maybe a Jira referring to these commits with a summary in description could help reassuring users about these changes. Both (Jira or not) fits
> with me in this case.
>
> My 2cts
>
> Jacques
>
>

[Scott Gray-3]

I think minor refactors (lots or few is irrelevant) shouldn't need a jira
ticket and aren't worth mentioning in a blog post.  Anything that requires
discussion and/or changes the behavior of the application, the API or
documentation should go through jira.

Regards
Scott

On Thu, 21 Mar 2019 at 10:19, Mathieu Lirzin <[hidden email]> wrote:

> Hello Michael,
>
> Michael Brohl <[hidden email]> writes:
>
> > don't we have Jira's for all these changes?
> >
> > If yes, please provide the issue number within the commit message so
> > that we have them in the monthly blog post/dev details.
> >
> > If no, we should have them, at least in the future.
>
> Sorry if the process I followed was not the right one.
>
> I must confess that the policy regarding how refactoring (done by
> committers) must be handled in term of JIRA creation, is not clear to
> me.  The block “When to create a Jira issue” on OFBiz wiki [1] is not
> helping much in that regard.  Maybe there is an implicit consensus in
> that regard that I am not aware of?
>
> My reasoning for not creating a JIRA was that those commits are pure
> refactoring meaning they are implementation details that don't change
> the observable behavior of the build and they are not part of a global
> plan.  Basically those cleanups happened by looking around while working
> on OFBIZ-10866 [2] but are unrelated to the endeavour of that task.
>
> What would you recommend in that scenario?
>
> > If these changes affect the documentation, the README.md should also
> > be edited to reflect them and stay in sync with the code.
>
> Sure I agree that's an important guideline to follow.
>
> Thanks.
>
> [1]
> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices
> [2] https://issues.apache.org/jira/browse/OFBIZ-10866
>
> --
> Mathieu Lirzin
> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>

[Jacques Le Roux]

We should complete and decide about https://cwiki.apache.org/confluence/display/OFBIZ/Guidelines+For+Using+JIRA

And then refer to it from where needed

That would be the last time we would have this convo ;)

Jacques

Le 27/03/2019 à 03:43, Scott Gray a écrit :

> I think minor refactors (lots or few is irrelevant) shouldn't need a jira
> ticket and aren't worth mentioning in a blog post.  Anything that requires
> discussion and/or changes the behavior of the application, the API or
> documentation should go through jira.
>
> Regards
> Scott
>
> On Thu, 21 Mar 2019 at 10:19, Mathieu Lirzin <[hidden email]> wrote:
>
>> Hello Michael,
>>
>> Michael Brohl <[hidden email]> writes:
>>
>>> don't we have Jira's for all these changes?
>>>
>>> If yes, please provide the issue number within the commit message so
>>> that we have them in the monthly blog post/dev details.
>>>
>>> If no, we should have them, at least in the future.
>> Sorry if the process I followed was not the right one.
>>
>> I must confess that the policy regarding how refactoring (done by
>> committers) must be handled in term of JIRA creation, is not clear to
>> me.  The block “When to create a Jira issue” on OFBiz wiki [1] is not
>> helping much in that regard.  Maybe there is an implicit consensus in
>> that regard that I am not aware of?
>>
>> My reasoning for not creating a JIRA was that those commits are pure
>> refactoring meaning they are implementation details that don't change
>> the observable behavior of the build and they are not part of a global
>> plan.  Basically those cleanups happened by looking around while working
>> on OFBIZ-10866 [2] but are unrelated to the endeavour of that task.
>>
>> What would you recommend in that scenario?
>>
>>> If these changes affect the documentation, the README.md should also
>>> be edited to reflect them and stay in sync with the code.
>> Sure I agree that's an important guideline to follow.
>>
>> Thanks.
>>
>> [1]
>> https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices
>> [2] https://issues.apache.org/jira/browse/OFBIZ-10866
>>
>> --
>> Mathieu Lirzin
>> GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37
>>