Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Michael Brohl <mi...@ecomify.de>]

Hi Jacques,

just stumbled upon this topic again, inline...

Am 20.09.19 um 17:39 schrieb Jacques Le Roux:
> In a 1st time I intend to do only what I wrote in OFBIZ-10226, 
> OFBIZ-10205 and this thread, ie indeed mostly "move them to 
> src/main/groovy". That's enough for my need.
>
> Using @CompileStatic is out of my scope because I want to keep Groovy 
> scripts dynamic.

I'd like to bring up this thead again and encourage everyone to read the 
mentioned article by David E. Jones: 
https://lists.apache.org/thread.html/fd68dff364fde41dcb0d0d0384ebf169cbaa1e8e6c6ac60701d3d774%40%3Cdev.ofbiz.apache.org%3E

We should be careful and act responsible when deciding certain 
principles and patterns. While it is of course more simple for 
developers to have it dynamic it might be a nightmare in real world 
projects with huge traffic. We have our experiences with this.

We had this discussion in the aforementioned thread. One argument 
against is "premature optimization" which is a killer argument to end 
such discussions. Of course there will be perfomance metrics only if we 
would implement the two patterns and compare runtime in a relevant load 
scenario which is not achievable.

One can very well rely on the experiences of others and make use of 
patterns to avoid problems in the later run. It would be real bad for 
the project if we do mass changes and ignore these experiences just to 
end up with users having serious production problems.

So I ask everyone involved to act responsible and take these 
informations into account when changing the code base.

Thanks,

Michael

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Pierre Smits <pi...@apache.org>]

Requests for feature branches in the OFBiz repositories received a lot of
push-back from PMC-members and committers in the past due to perceived high
maintenance burdens (ensuring the branch stayed in sync with where they
were derived from) placed on those willing to do that. I guess, the number
of those branches in svn (and restrictions thereon) led to this. I also
guess those complaining were the ones not often willing to participate in
those efforts.

With the implementation of Git as our prime version control solution, any
community member can start the feature branch and share it - for
collaboration and/or review purposes - via their public Github fork. With
this approach, the burden is placed on the member (not necessarily a PMC
Member or committer) willing to act as lead to keep the branch up to date.
And when the maintainer (as the driving party) feels confident it is ready
to be included in the OFBiz repository it can be introduced in the form of
a pull request. Updates to the community of progress can - as always - take
place via ticket comments and/or postings to the mailing list(s).

IMO, this path should be followed by every community member considering to
introduce new plugins or considering a large number of improvements on one
or more components.

However, there is also a drawback to this. This approach can lead to a big
contribution (in the form of a lot of changes to a lot of files) that won't
get the attention of fellow community members that the initiative deserves.
Over the years committers have rejected such from non-privileged
contributors because of the effort involved regarding review. And postings
on the ml hadn't helped the community. One could even argue that perception
regarding this has led to the floundering of many of the feature (and wish)
tickets in our JIRA (see [1]), and maybe even loss of contributors.

How will this be prevented?


[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20OFBIZ%20AND%20issuetype%20in%20(%22New%20Feature%22%2C%20Wish)%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Sun, Feb 2, 2020 at 5:01 PM Michael Brohl <mi...@ecomify.de>
wrote:

> +1, with a remark
>
> We should do the development on a feature branch based on trunk (instead
> of a release branch) and constantly merge trunk into it. This would
> allow to develop very near to the ongoing developments in other areas
> and merge back easily once the feature branch gets accepted. It would
> also allow field tests using the feature branch with the latest feature
> set.
>
> Thanks,
>
> Michael Brohl
>
> ecomify GmbH - www.ecomify.de
>
>
> Am 02.02.20 um 16:21 schrieb Pierre Smits:
> > Hi All,
> >
> > Given that this is yet another major refactoring endeavour and can, when
> we
> > do this on trunk, be dragged on for years given the limited number of
> > contributors. Like is happening right now with those other refactoring
> > efforts, such as the move from xml-services to script services or the
> > migrate-documentation effort.
> >
> > If we do this on trunk, there is the risk that we confront our adopters
> > (meaning their developers) with scripts in inconsistent locations. This
> > will surely hinder the appeal of OFBiz.
> >
> > Michael stated:
> >
> > Of course there will be perfomance metrics only if we would implement the
> > two patterns and compare runtime in a relevant load scenario which is not
> > achievable.
> >
> > When done on trunk, Michael is correct: we can't measure and compare
> impact
> > between the two scenarios.
> > But we can measure and compare when we don't do this on trunk, but
> instead
> > in a separate development branch based on one of the releases. Then we
> can
> > have a CI perform the necessary tests on both, and we get insight in the
> > performance gains/penalties.
> >
> > And when there are significant performance gains, we can work to merge
> the
> > changes back into trunk.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> > *Apache Directory <https://directory.apache.org>, PMC Member*
> > Apache Incubator <https://incubator.apache.org>, committer
> > *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> privileges)
> > since 2008*
> > Apache Steve <https://steve.apache.org>, committer
> >
> >
> > On Fri, Jan 31, 2020 at 5:47 PM Michael Brohl <mi...@ecomify.de>
> > wrote:
> >
> >> Hi Jacques,
> >>
> >> just stumbled upon this topic again, inline...
> >>
> >> Am 20.09.19 um 17:39 schrieb Jacques Le Roux:
> >>> In a 1st time I intend to do only what I wrote in OFBIZ-10226,
> >>> OFBIZ-10205 and this thread, ie indeed mostly "move them to
> >>> src/main/groovy". That's enough for my need.
> >>>
> >>> Using @CompileStatic is out of my scope because I want to keep Groovy
> >>> scripts dynamic.
> >> I'd like to bring up this thead again and encourage everyone to read the
> >> mentioned article by David E. Jones:
> >>
> >>
> https://lists.apache.org/thread.html/fd68dff364fde41dcb0d0d0384ebf169cbaa1e8e6c6ac60701d3d774%40%3Cdev.ofbiz.apache.org%3E
> >>
> >> We should be careful and act responsible when deciding certain
> >> principles and patterns. While it is of course more simple for
> >> developers to have it dynamic it might be a nightmare in real world
> >> projects with huge traffic. We have our experiences with this.
> >>
> >> We had this discussion in the aforementioned thread. One argument
> >> against is "premature optimization" which is a killer argument to end
> >> such discussions. Of course there will be perfomance metrics only if we
> >> would implement the two patterns and compare runtime in a relevant load
> >> scenario which is not achievable.
> >>
> >> One can very well rely on the experiences of others and make use of
> >> patterns to avoid problems in the later run. It would be real bad for
> >> the project if we do mass changes and ignore these experiences just to
> >> end up with users having serious production problems.
> >>
> >> So I ask everyone involved to act responsible and take these
> >> informations into account when changing the code base.
> >>
> >> Thanks,
> >>
> >> Michael
> >>
> >>
> >>
> >>
>
>

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Michael Brohl <mi...@ecomify.de>]

+1, with a remark

We should do the development on a feature branch based on trunk (instead 
of a release branch) and constantly merge trunk into it. This would 
allow to develop very near to the ongoing developments in other areas 
and merge back easily once the feature branch gets accepted. It would 
also allow field tests using the feature branch with the latest feature set.

Thanks,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 02.02.20 um 16:21 schrieb Pierre Smits:
> Hi All,
>
> Given that this is yet another major refactoring endeavour and can, when we
> do this on trunk, be dragged on for years given the limited number of
> contributors. Like is happening right now with those other refactoring
> efforts, such as the move from xml-services to script services or the
> migrate-documentation effort.
>
> If we do this on trunk, there is the risk that we confront our adopters
> (meaning their developers) with scripts in inconsistent locations. This
> will surely hinder the appeal of OFBiz.
>
> Michael stated:
>
> Of course there will be perfomance metrics only if we would implement the
> two patterns and compare runtime in a relevant load scenario which is not
> achievable.
>
> When done on trunk, Michael is correct: we can't measure and compare impact
> between the two scenarios.
> But we can measure and compare when we don't do this on trunk, but instead
> in a separate development branch based on one of the releases. Then we can
> have a CI perform the necessary tests on both, and we get insight in the
> performance gains/penalties.
>
> And when there are significant performance gains, we can work to merge the
> changes back into trunk.
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
> since 2008*
> Apache Steve <https://steve.apache.org>, committer
>
>
> On Fri, Jan 31, 2020 at 5:47 PM Michael Brohl <mi...@ecomify.de>
> wrote:
>
>> Hi Jacques,
>>
>> just stumbled upon this topic again, inline...
>>
>> Am 20.09.19 um 17:39 schrieb Jacques Le Roux:
>>> In a 1st time I intend to do only what I wrote in OFBIZ-10226,
>>> OFBIZ-10205 and this thread, ie indeed mostly "move them to
>>> src/main/groovy". That's enough for my need.
>>>
>>> Using @CompileStatic is out of my scope because I want to keep Groovy
>>> scripts dynamic.
>> I'd like to bring up this thead again and encourage everyone to read the
>> mentioned article by David E. Jones:
>>
>> https://lists.apache.org/thread.html/fd68dff364fde41dcb0d0d0384ebf169cbaa1e8e6c6ac60701d3d774%40%3Cdev.ofbiz.apache.org%3E
>>
>> We should be careful and act responsible when deciding certain
>> principles and patterns. While it is of course more simple for
>> developers to have it dynamic it might be a nightmare in real world
>> projects with huge traffic. We have our experiences with this.
>>
>> We had this discussion in the aforementioned thread. One argument
>> against is "premature optimization" which is a killer argument to end
>> such discussions. Of course there will be perfomance metrics only if we
>> would implement the two patterns and compare runtime in a relevant load
>> scenario which is not achievable.
>>
>> One can very well rely on the experiences of others and make use of
>> patterns to avoid problems in the later run. It would be real bad for
>> the project if we do mass changes and ignore these experiences just to
>> end up with users having serious production problems.
>>
>> So I ask everyone involved to act responsible and take these
>> informations into account when changing the code base.
>>
>> Thanks,
>>
>> Michael
>>
>>
>>
>>

Re: [DISCUSSION] Best of both Groovy worlds: compile and on the fly

[Pierre Smits <pi...@apache.org>]

Hi All,

Given that this is yet another major refactoring endeavour and can, when we
do this on trunk, be dragged on for years given the limited number of
contributors. Like is happening right now with those other refactoring
efforts, such as the move from xml-services to script services or the
migrate-documentation effort.

If we do this on trunk, there is the risk that we confront our adopters
(meaning their developers) with scripts in inconsistent locations. This
will surely hinder the appeal of OFBiz.

Michael stated:

Of course there will be perfomance metrics only if we would implement the
two patterns and compare runtime in a relevant load scenario which is not
achievable.

When done on trunk, Michael is correct: we can't measure and compare impact
between the two scenarios.
But we can measure and compare when we don't do this on trunk, but instead
in a separate development branch based on one of the releases. Then we can
have a CI perform the necessary tests on both, and we get insight in the
performance gains/penalties.

And when there are significant performance gains, we can work to merge the
changes back into trunk.

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Fri, Jan 31, 2020 at 5:47 PM Michael Brohl <mi...@ecomify.de>
wrote:

> Hi Jacques,
>
> just stumbled upon this topic again, inline...
>
> Am 20.09.19 um 17:39 schrieb Jacques Le Roux:
> > In a 1st time I intend to do only what I wrote in OFBIZ-10226,
> > OFBIZ-10205 and this thread, ie indeed mostly "move them to
> > src/main/groovy". That's enough for my need.
> >
> > Using @CompileStatic is out of my scope because I want to keep Groovy
> > scripts dynamic.
>
> I'd like to bring up this thead again and encourage everyone to read the
> mentioned article by David E. Jones:
>
> https://lists.apache.org/thread.html/fd68dff364fde41dcb0d0d0384ebf169cbaa1e8e6c6ac60701d3d774%40%3Cdev.ofbiz.apache.org%3E
>
> We should be careful and act responsible when deciding certain
> principles and patterns. While it is of course more simple for
> developers to have it dynamic it might be a nightmare in real world
> projects with huge traffic. We have our experiences with this.
>
> We had this discussion in the aforementioned thread. One argument
> against is "premature optimization" which is a killer argument to end
> such discussions. Of course there will be perfomance metrics only if we
> would implement the two patterns and compare runtime in a relevant load
> scenario which is not achievable.
>
> One can very well rely on the experiences of others and make use of
> patterns to avoid problems in the later run. It would be real bad for
> the project if we do mass changes and ignore these experiences just to
> end up with users having serious production problems.
>
> So I ask everyone involved to act responsible and take these
> informations into account when changing the code base.
>
> Thanks,
>
> Michael
>
>
>
>