[ALL] components still using Travis

2022-03-29 Thread sebb 
It looks like there is a general move to switch from Travis to GitHub Actions.
AFAICT the following components are still using Travis:

geometry
jelly
jxpath
math
numbers
rng
weaver

Do we need to move these as well?

BTW, emails from GHA runs can now be directed to project mailing
lists, which is great (*)
See: https://s.apache.org/asfyaml-gha

e.g. update .asf.yaml to include:
notifications:
...
  jobs: notificati...@commons.apache.org

Sebb.
(*) Travis always had this, but recently switched to a new email
system which means all such mails have to be moderated.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] components still using Travis

2022-03-29 Thread Matt Juntunen 
Hi Sebb,

Yep, geometry is still using Travis. I've never used GitHub Actions so
I'm not sure what it's capable of. Are there any specific features it
provides that are driving the migration to it? Or is it more a matter
of community preference? Either way is fine, I'm just curious.

Regards,
Matt J

On Tue, Mar 29, 2022 at 7:22 AM sebb  wrote:
>
> It looks like there is a general move to switch from Travis to GitHub Actions.
> AFAICT the following components are still using Travis:
>
> geometry
> jelly
> jxpath
> math
> numbers
> rng
> weaver
>
> Do we need to move these as well?
>
> BTW, emails from GHA runs can now be directed to project mailing
> lists, which is great (*)
> See: https://s.apache.org/asfyaml-gha
>
> e.g. update .asf.yaml to include:
> notifications:
> ...
>   jobs: notificati...@commons.apache.org
>
> Sebb.
> (*) Travis always had this, but recently switched to a new email
> system which means all such mails have to be moderated.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] components still using Travis

2022-03-29 Thread Gilles Sadowski 
Hello.

Le mar. 29 mars 2022 à 13:22, sebb  a écrit :
>
> It looks like there is a general move to switch from Travis to GitHub Actions.

AFAIK, there has never been a clear explanation for that move.

> AFAICT the following components are still using Travis:
>
> geometry
> jelly
> jxpath
> math
> numbers
> rng
> weaver

statistics

>
> Do we need to move these as well?

For consistency, or ease of maintenance, provided it is indeed
the case that everything can be configured from ".asf.yaml" (i.e.
no "login in on GH" required).

Regards,
Gilles

>
> BTW, emails from GHA runs can now be directed to project mailing
> lists, which is great (*)
> See: https://s.apache.org/asfyaml-gha
>
> e.g. update .asf.yaml to include:
> notifications:
> ...
>   jobs: notificati...@commons.apache.org
>
> Sebb.
> (*) Travis always had this, but recently switched to a new email
> system which means all such mails have to be moderated.
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] components still using Travis

2022-03-29 Thread Alex Herbert 
On Tue, 29 Mar 2022 at 12:22, sebb  wrote:

> It looks like there is a general move to switch from Travis to GitHub
> Actions.
> AFAICT the following components are still using Travis:
>
> geometry
> jelly
> jxpath
> math
> numbers
> rng
> weaver
>
> Do we need to move these as well?
>

In terms of supporting a CI build on all PRs for a range of platforms then
the two provide the same functionality. I am not opposed to moving to GHA.
It just did not seem necessary.

One issue I have with GH actions is that when a build fails there is no
option to scroll the build output log to the end to see the error. This is
useful for maven's verbose output logs, especially with the multi-module
projects (geometry, math, numbers, rng, statistics). Looking at a recent GH
build you can search in the output log, but not scroll to the end. Maybe
this is different if the build fails; I only looked at one that passed.

The feature I liked from Travis was the integration of coverage reports
from coveralls. This would red light a PR in the main page if coverage had
dropped. There is no coveralls GHA. I installed the Codecov action for
[Collections] as a test a few months ago and it has been sending coverage
emails to our dev list since. You can click through and scroll the report.
I do not think it red lights a PR for low coverage so you have to read the
report. I am undecided if I prefer the report. No-one else seems to have
commented either way. But I think it important that any PR has automated
checks that the new code is executed.

One thing I have noticed is that Travis is a bit flaky. Sometimes it does
not run for PRs. We had a few spells on some projects where the Travis CI
did not link up then magically started working again with no changes to
settings. It's been a while since I looked at a PR using Travis and the
coveralls reports. So I will open one now and see if the integration is
still there.

Having just opened one it does not log a Travis CI build in the GitHub
page. LGTM analysis is running. Travis-ci.com does not pick up the PR. The
last build was 6 days ago on master. [1]

The settings are all good to build PRs. So this is an example of the flaky
support we get from Travis. If nothing else this is a reason to change to
GHA.

Matt uses PRs a lot on geometry to check builds on multiple platforms.
Perhaps he can feedback on whether the Travis integration is working there.


>
> BTW, emails from GHA runs can now be directed to project mailing
> lists, which is great (*)
> See: https://s.apache.org/asfyaml-gha
>
>
Currently if I commit something that breaks a CI build on Travis (or
Jenkins which we use for snapshot deployment) then I receive an e-mail. I
am more likely to respond to personal e-mails than e-mails to a list. Can
GHA target both types of mail?

Alex

[1] https://app.travis-ci.com/github/apache/commons-rng

Re: [ALL] components still using Travis

2022-03-29 Thread Gilles Sadowski 
Hello.

Le mar. 29 mars 2022 à 15:23, Alex Herbert  a écrit :
>
> [...]
>
> The feature I liked from Travis was the integration of coverage reports
> from coveralls. This would red light a PR in the main page if coverage had
> dropped. There is no coveralls GHA. I installed the Codecov action for
> [Collections] as a test a few months ago and it has been sending coverage
> emails to our dev list since. You can click through and scroll the report.
> I do not think it red lights a PR for low coverage so you have to read the
> report. I am undecided if I prefer the report. No-one else seems to have
> commented either way. But I think it important that any PR has automated
> checks that the new code is executed.

IMO, it would be a regression if the move to GH has removed that feature.

Gilles

>
> [...]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] components still using Travis

2022-03-29 Thread Alex Herbert 
On Tue, 29 Mar 2022 at 14:43, Gilles Sadowski  wrote:

> Hello.
>
> Le mar. 29 mars 2022 à 15:23, Alex Herbert  a
> écrit :
> >
> > [...]
> >
> > The feature I liked from Travis was the integration of coverage reports
> > from coveralls. This would red light a PR in the main page if coverage
> had
> > dropped. There is no coveralls GHA. I installed the Codecov action for
> > [Collections] as a test a few months ago and it has been sending coverage
> > emails to our dev list since. You can click through and scroll the
> report.
> > I do not think it red lights a PR for low coverage so you have to read
> the
> > report. I am undecided if I prefer the report. No-one else seems to have
> > commented either way. But I think it important that any PR has automated
> > checks that the new code is executed.
>
> IMO, it would be a regression if the move to GH has removed that feature.
>

+1. But flaky integration is a bigger issue. Without a CI build you cannot
get the coverage failure report at all.

There is a way to restart PR builds on Travis CI (e.g. if they fail
spuriously due to randomness as occurs in [RNG]). But there is no way to
force a link up other than waiting a few hours/days and pushing to the PR
branch.

Looking at Travis CI.com, it was running builds for the Geometry PR for
issue 142. The last PR build was 11 days ago, and then a build on master 3
days ago when it was merged. But RNG last had a PR 6 months ago; Numbers
had one 5 months ago. Travis has been building master for all
recent commits.

[1] https://app.travis-ci.com/github/apache/commons-geometry/pull_requests
[2] https://app.travis-ci.com/github/apache/commons-rng/pull_requests
[3] https://app.travis-ci.com/github/apache/commons-numbers/pull_requests

Re: [ALL] components still using Travis

2022-03-29 Thread sebb 
On Tue, 29 Mar 2022 at 13:57, Matt Juntunen  wrote:
>
> Hi Sebb,
>
> Yep, geometry is still using Travis. I've never used GitHub Actions so
> I'm not sure what it's capable of. Are there any specific features it
> provides that are driving the migration to it? Or is it more a matter
> of community preference? Either way is fine, I'm just curious.

It looks like Infra may be intending to migrate projects:
https://cwiki.apache.org/confluence/display/INFRA/Travis+to+GitHub+Actions+Migration

> Regards,
> Matt J
>
> On Tue, Mar 29, 2022 at 7:22 AM sebb  wrote:
> >
> > It looks like there is a general move to switch from Travis to GitHub 
> > Actions.
> > AFAICT the following components are still using Travis:
> >
> > geometry
> > jelly
> > jxpath
> > math
> > numbers
> > rng
> > weaver
> >
> > Do we need to move these as well?
> >
> > BTW, emails from GHA runs can now be directed to project mailing
> > lists, which is great (*)
> > See: https://s.apache.org/asfyaml-gha
> >
> > e.g. update .asf.yaml to include:
> > notifications:
> > ...
> >   jobs: notificati...@commons.apache.org
> >
> > Sebb.
> > (*) Travis always had this, but recently switched to a new email
> > system which means all such mails have to be moderated.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] components still using Travis

2022-03-29 Thread Rob Tompkins 
I wonder if the python script will be effective in doing the migration 
properly. I’ll try to carve some time out to help here.

-Rob 

> On Mar 29, 2022, at 10:19 AM, sebb  wrote:
> 
> On Tue, 29 Mar 2022 at 13:57, Matt Juntunen  wrote:
>> 
>> Hi Sebb,
>> 
>> Yep, geometry is still using Travis. I've never used GitHub Actions so
>> I'm not sure what it's capable of. Are there any specific features it
>> provides that are driving the migration to it? Or is it more a matter
>> of community preference? Either way is fine, I'm just curious.
> 
> It looks like Infra may be intending to migrate projects:
> https://cwiki.apache.org/confluence/display/INFRA/Travis+to+GitHub+Actions+Migration
> 
>> Regards,
>> Matt J
>> 
>> On Tue, Mar 29, 2022 at 7:22 AM sebb  wrote:
>>> 
>>> It looks like there is a general move to switch from Travis to GitHub 
>>> Actions.
>>> AFAICT the following components are still using Travis:
>>> 
>>> geometry
>>> jelly
>>> jxpath
>>> math
>>> numbers
>>> rng
>>> weaver
>>> 
>>> Do we need to move these as well?
>>> 
>>> BTW, emails from GHA runs can now be directed to project mailing
>>> lists, which is great (*)
>>> See: https://s.apache.org/asfyaml-gha
>>> 
>>> e.g. update .asf.yaml to include:
>>> notifications:
>>> ...
>>>  jobs: notificati...@commons.apache.org
>>> 
>>> Sebb.
>>> (*) Travis always had this, but recently switched to a new email
>>> system which means all such mails have to be moderated.
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] components still using Travis

2022-03-29 Thread sebb 
On Tue, 29 Mar 2022 at 15:27, Rob Tompkins  wrote:
>
> I wonder if the python script will be effective in doing the migration 
> properly. I’ll try to carve some time out to help here.

In the case of Commons, most of the components have very similar
needs, so one can probably just copy existing workflows from another
component and adjust slightly.

> -Rob
>
> > On Mar 29, 2022, at 10:19 AM, sebb  wrote:
> >
> > On Tue, 29 Mar 2022 at 13:57, Matt Juntunen  
> > wrote:
> >>
> >> Hi Sebb,
> >>
> >> Yep, geometry is still using Travis. I've never used GitHub Actions so
> >> I'm not sure what it's capable of. Are there any specific features it
> >> provides that are driving the migration to it? Or is it more a matter
> >> of community preference? Either way is fine, I'm just curious.
> >
> > It looks like Infra may be intending to migrate projects:
> > https://cwiki.apache.org/confluence/display/INFRA/Travis+to+GitHub+Actions+Migration
> >
> >> Regards,
> >> Matt J
> >>
> >> On Tue, Mar 29, 2022 at 7:22 AM sebb  wrote:
> >>>
> >>> It looks like there is a general move to switch from Travis to GitHub 
> >>> Actions.
> >>> AFAICT the following components are still using Travis:
> >>>
> >>> geometry
> >>> jelly
> >>> jxpath
> >>> math
> >>> numbers
> >>> rng
> >>> weaver
> >>>
> >>> Do we need to move these as well?
> >>>
> >>> BTW, emails from GHA runs can now be directed to project mailing
> >>> lists, which is great (*)
> >>> See: https://s.apache.org/asfyaml-gha
> >>>
> >>> e.g. update .asf.yaml to include:
> >>> notifications:
> >>> ...
> >>>  jobs: notificati...@commons.apache.org
> >>>
> >>> Sebb.
> >>> (*) Travis always had this, but recently switched to a new email
> >>> system which means all such mails have to be moderated.
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] components still using Travis

2022-03-29 Thread Rob Tompkins 


> On Mar 29, 2022, at 10:51 AM, sebb  wrote:
> 
> On Tue, 29 Mar 2022 at 15:27, Rob Tompkins  > wrote:
>> 
>> I wonder if the python script will be effective in doing the migration 
>> properly. I’ll try to carve some time out to help here.
> 
> In the case of Commons, most of the components have very similar
> needs, so one can probably just copy existing workflows from another
> component and adjust slightly.

With youi there….just thinking that it might not be exactly 1-to-1 such that a 
python script automating the migration would work.

-Rob

> 
>> -Rob
>> 
>>> On Mar 29, 2022, at 10:19 AM, sebb  wrote:
>>> 
>>> On Tue, 29 Mar 2022 at 13:57, Matt Juntunen  
>>> wrote:
 
 Hi Sebb,
 
 Yep, geometry is still using Travis. I've never used GitHub Actions so
 I'm not sure what it's capable of. Are there any specific features it
 provides that are driving the migration to it? Or is it more a matter
 of community preference? Either way is fine, I'm just curious.
>>> 
>>> It looks like Infra may be intending to migrate projects:
>>> https://cwiki.apache.org/confluence/display/INFRA/Travis+to+GitHub+Actions+Migration
>>> 
 Regards,
 Matt J
 
 On Tue, Mar 29, 2022 at 7:22 AM sebb  wrote:
> 
> It looks like there is a general move to switch from Travis to GitHub 
> Actions.
> AFAICT the following components are still using Travis:
> 
> geometry
> jelly
> jxpath
> math
> numbers
> rng
> weaver
> 
> Do we need to move these as well?
> 
> BTW, emails from GHA runs can now be directed to project mailing
> lists, which is great (*)
> See: https://s.apache.org/asfyaml-gha
> 
> e.g. update .asf.yaml to include:
> notifications:
> ...
> jobs: notificati...@commons.apache.org
> 
> Sebb.
> (*) Travis always had this, but recently switched to a new email
> system which means all such mails have to be moderated.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org
 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
>> 
>> For additional commands, e-mail: dev-h...@commons.apache.org 
>> 
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
> 
> For additional commands, e-mail: dev-h...@commons.apache.org 
>

Re: [Math] Review of "genetic algorithm" module

2022-03-29 Thread Avijit Basak 
Hi All

 Please find my comments below.

[...]
>Just quickly commenting on this point.

>IIUC, your purpose is for users to be able to run (an example
>application of) the old implementation.
>
>This can be achieved by having all the "legacy" codes within
>module
>  commons-math-examples/examples-ga/examples-ga-math-functions
>(note: No "legacy" in the module's name), within a dedicated
>  o.a.c.m.examples.ga.mathfunctions.legacy
>package.
>
>This code is then called by the exact same code/application as
>for the new implementation (with the corresponding command
>line switch):
>  $ java -jar examples-ga-app.jar --legacy ... rest of the args ...
>
>Users can thus perform 2 runs; once with "--legacy" and one
>without it, and reach some conclusions.
>
>The duplicate codes only bring maintenance burden (to ensure
>that the "legacy" and non-"legacy" modules do indeed aim at
>solving the same problem).
>Whenever we then decide that the new code has been thoroughly
>tested, removal of the
>  o.a.c.m.examples.ga.mathfunctions.legacy
>package will be a minimal change (as compared to the removal
>of a module)

--I have made the changes and created a new PR. Kindly review the same and
share your thoughts.
*https://github.com/apache/commons-math/pull/208
*


Thanks & Regards
--Avijit Basak



On Mon, 28 Mar 2022 at 18:36, Gilles Sadowski  wrote:

> Hello.
>
> Le lun. 28 mars 2022 à 10:15, Avijit Basak  a
> écrit :
> >
> > [...]
> >
> > >The various "Standalone" classes also look quite similar; consolidating
> the
> > >"examples-ga" module (including full Javadoc) is necessary.
> > -- Could you please elaborate it more. IMHO as StandAlone classes are
> > dedicated to the specific module only, it would remain separate. Since we
> > have used a single domain to show utility of the different
> > types(adaptive/simple) of GA some classes have become similar.
> >
> > >I still don't
> > >understand why there are "...-legacy" modules in module "examples-ga".
> > >If you want to offer the option of running the "old" implementation, you
> > >could add a "legacy" flag (as "@Option" in the "Standalone"
> application).
> > -- There was a discussion on this some time back. The sole purpose of
> > keeping the legacy example module is for comparison with the new
> > implementation. It will be easier for anyone to visualize the quality
> > improvement we achieved here. I don't want to mix(by legacy flag) this
> > anyway with the new implementation.
> >
>
> Just quickly commenting on this point.
>
> IIUC, your purpose is for users to be able to run (an example
> application of) the old implementation.
>
> This can be achieved by having all the "legacy" codes within
> module
>   commons-math-examples/examples-ga/examples-ga-math-functions
> (note: No "legacy" in the module's name), within a dedicated
>   o.a.c.m.examples.ga.mathfunctions.legacy
> package.
>
> This code is then called by the exact same code/application as
> for the new implementation (with the corresponding command
> line switch):
>   $ java -jar examples-ga-app.jar --legacy ... rest of the args ...
>
> Users can thus perform 2 runs; once with "--legacy" and one
> without it, and reach some conclusions.
>
> The duplicate codes only bring maintenance burden (to ensure
> that the "legacy" and non-"legacy" modules do indeed aim at
> solving the same problem).
> Whenever we then decide that the new code has been thoroughly
> tested, removal of the
>   o.a.c.m.examples.ga.mathfunctions.legacy
> package will be a minimal change (as compared to the removal
> of a module).
>
> Regards,
> Gilles
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-- 
Avijit Basak