Re: [numbers] Release 1.0-beta1 Follow-Up

[Gilles Sadowski]

Hello.

Le mer. 8 avr. 2020 à 03:35, Matt Juntunen  a écrit :
>
> Hi all,
>
> I just completed the commons-numbers 1.0-beta1 release

Thanks!

> and I have a couple of follow-up notes:
>
>   *   I was unable to add the release using the form at 
> https://reporter.apache.org/addrelease.html?commons.

Done.

> I received an error message saying that I was not part of the PMC or an ASF 
> member.
>   *   I did not make any changes in JIRA for the release. Should we create a 
> 1.0-beta1 release in JIRA

Done.

> and close all resolved issues

Done.

> or wait until the full 1.0 release?

I figure out that it would be confusing if there are subsequent beta
releases:  All resolved issues up to now will appear in every one of
them, thus hiding (or making it more difficult to follow) progress.

Best,
Gilles

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

[numbers] Release 1.0-beta1 Follow-Up

[Matt Juntunen]

Hi all,

I just completed the commons-numbers 1.0-beta1 release and I have a couple of 
follow-up notes:

  *   I was unable to add the release using the form at 
https://reporter.apache.org/addrelease.html?commons. I received an error 
message saying that I was not part of the PMC or an ASF member.
  *   I did not make any changes in JIRA for the release. Should we create a 
1.0-beta1 release in JIRA and close all resolved issues or wait until the full 
1.0 release?

Regards,
Matt

Re: [numbers] Release?

[Gilles Sadowski]

Hello.

Le mer. 25 mars 2020 à 20:28, Matt Juntunen
 a écrit :
>
> Thanks everyone for the information. I'll start working toward this and send 
> out an email when I'm ready to start cutting the release.
>
> One thing I notice is that there isn't a commons-numbers user guide to speak 
> of.

There is a JIRA issue
https://issues.apache.org/jira/projects/NUMBERS/issues/NUMBERS-70
but concrete attempts did not go very far...

> Is this something that needs to be added before the beta release?

It can always be added later.
Also, most codes are fairly self-documenting.

Best,
Gilles

> [...]

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

Re: [numbers] Release?

[Matt Juntunen]

Thanks everyone for the information. I'll start working toward this and send 
out an email when I'm ready to start cutting the release.

One thing I notice is that there isn't a commons-numbers user guide to speak 
of. Is this something that needs to be added before the beta release?

-Matt

From: Gilles Sadowski 
Sent: Tuesday, March 24, 2020 1:46 PM
To: Commons Developers List 
Subject: Re: [numbers] Release?

Hello.

Le mar. 24 mars 2020 à 16:19, Alex Herbert  a écrit :
>
>
> On 24/03/2020 13:30, Rob Tompkins wrote:
> > Yes you’re totally welcome to, and the directions are here: 
> > http://commons.apache.org/releases/index.html 
> > <http://commons.apache.org/releases/index.html>
> >
> > Feel free to ask questions and I would suggest using the release plugin 
> > portion of the release preparation page. If there’s confusion (I would 
> > expect some obsolescence) on the page do make note of it, and I would be 
> > happy to update it as we see fit.
> >
> > All the best,
> > -Rob
> The [rng] project has a useful release guide for a multi-module project
> (I think partly written by Rob):
>
> doc/release/release.howto.txt

I started it for "Commons Math" when I attempted my first release of it,
and everything available was flawed in one way or another.
It was later modified for git-based development, then copied (mutatis
mutandis) into [RNG].

Part of the release process is nevertheless based on tools initiated
by Rob.  But, last time I tried, there were issues because (AFAICT)
modularity was not fully taken into account.  I don't whether it has
improved (I seem to recall of lingering JIRA reports).

It would certainly be great to consolidate the docs.
At least, components
 * RNG
 * Statistics
 * Numbers
 * Geometry
should behave the same wrt the release process.

>
>
> Q. Is this to be released as a beta?
>
> The commons release page linked indicates the artefacts would be named
>
> commons-numbers-XXX-1.0-B1.jar
>
>
> It does not state anything about changing the package coordinates.

I asked several times for confirmation on this ML: IIRC, conclusion is
that, while in "beta", it is OK
 * to break compatibility, and
 * to cause JAR hell.
[The advantage is that users can drop replacement JARs and see the
effect of changes without touchin their code.]

> Releasing under beta does allow changes as there are "no guarantees of
> stability or maintenance". So this could be released and we can still
> change the API. For instance there is the Complex streams modules that
> is due in part to be dropped and replaced by a ComplexList
> representation of many complex numbers. I hope to get back to working on
> this soon.

Since we know that ComplexUtils will not make to the official release
(because Alex's proposal is convincingly better), I'd remove that module
from the release branch.

Thank ou for stepping up,
Gilles

>>> [...]

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

Re: [numbers] Release?

[Gilles Sadowski]

Hello.

Le mar. 24 mars 2020 à 16:19, Alex Herbert  a écrit :
>
>
> On 24/03/2020 13:30, Rob Tompkins wrote:
> > Yes you’re totally welcome to, and the directions are here: 
> > http://commons.apache.org/releases/index.html 
> > 
> >
> > Feel free to ask questions and I would suggest using the release plugin 
> > portion of the release preparation page. If there’s confusion (I would 
> > expect some obsolescence) on the page do make note of it, and I would be 
> > happy to update it as we see fit.
> >
> > All the best,
> > -Rob
> The [rng] project has a useful release guide for a multi-module project
> (I think partly written by Rob):
>
> doc/release/release.howto.txt

I started it for "Commons Math" when I attempted my first release of it,
and everything available was flawed in one way or another.
It was later modified for git-based development, then copied (mutatis
mutandis) into [RNG].

Part of the release process is nevertheless based on tools initiated
by Rob.  But, last time I tried, there were issues because (AFAICT)
modularity was not fully taken into account.  I don't whether it has
improved (I seem to recall of lingering JIRA reports).

It would certainly be great to consolidate the docs.
At least, components
 * RNG
 * Statistics
 * Numbers
 * Geometry
should behave the same wrt the release process.

>
>
> Q. Is this to be released as a beta?
>
> The commons release page linked indicates the artefacts would be named
>
> commons-numbers-XXX-1.0-B1.jar
>
>
> It does not state anything about changing the package coordinates.

I asked several times for confirmation on this ML: IIRC, conclusion is
that, while in "beta", it is OK
 * to break compatibility, and
 * to cause JAR hell.
[The advantage is that users can drop replacement JARs and see the
effect of changes without touchin their code.]

> Releasing under beta does allow changes as there are "no guarantees of
> stability or maintenance". So this could be released and we can still
> change the API. For instance there is the Complex streams modules that
> is due in part to be dropped and replaced by a ComplexList
> representation of many complex numbers. I hope to get back to working on
> this soon.

Since we know that ComplexUtils will not make to the official release
(because Alex's proposal is convincingly better), I'd remove that module
from the release branch.

Thank ou for stepping up,
Gilles

>>> [...]

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

Re: [numbers] Release?

[Alex Herbert]

On 24/03/2020 13:30, Rob Tompkins wrote:

Yes you’re totally welcome to, and the directions are here: 
http://commons.apache.org/releases/index.html 
<http://commons.apache.org/releases/index.html>

Feel free to ask questions and I would suggest using the release plugin portion 
of the release preparation page. If there’s confusion (I would expect some 
obsolescence) on the page do make note of it, and I would be happy to update it 
as we see fit.

All the best,
-Rob
The [rng] project has a useful release guide for a multi-module project 
(I think partly written by Rob):


doc/release/release.howto.txt


Q. Is this to be released as a beta?

The commons release page linked indicates the artefacts would be named

commons-numbers-XXX-1.0-B1.jar


It does not state anything about changing the package coordinates. 
Releasing under beta does allow changes as there are "no guarantees of 
stability or maintenance". So this could be released and we can still 
change the API. For instance there is the Complex streams modules that 
is due in part to be dropped and replaced by a ComplexList 
representation of many complex numbers. I hope to get back to working on 
this soon.


Alex




On Mar 24, 2020, at 9:26 AM, Matt Juntunen  wrote:

Hello,

Am I able to perform this beta release of numbers now that I am a committer? If 
so, how would I go about it?

Thanks,
Matt

From: Matt Juntunen 
Sent: Saturday, March 7, 2020 7:37 AM
To: Alex Herbert ; Commons Developers List 

Subject: Re: [numbers] Release?

Hello,

Any progress here?

Regards,
Matt

From: Alex Herbert 
Sent: Friday, February 21, 2020 8:20 PM
To: Commons Developers List 
Subject: Re: [numbers] Release?




On 22 Feb 2020, at 01:15, Gilles Sadowski  wrote:

Le sam. 22 févr. 2020 à 01:30, Alex Herbert mailto:alex.d.herb...@gmail.com>> a écrit :




On 22 Feb 2020, at 00:29, Gilles Sadowski  wrote:

Hi.

Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
 a écrit :

Are we waiting on anything for a numbers release?

I don't think so.

Are you talking about a beta release where the API is not yet frozen?

Yes.


I’m still testing versions of LinearCombination. But from the discussion on 
NUMBERS-142 [1] it seems the choice may be to just change the current class to 
use a more precise method. It will be slower than the current method but will 
have an ensured accuracy of 1 ULP. It will be much faster than BigDecimal. All 
the testing implementations can go into the examples module for reference.

I have 1 PR for Complex to add an internal version of Math.hypot (NUMBERS-143). 
I’ll go over this soon and bring it in. The method is faster and more accurate 
than Math.hypot.

I think Complex is ISO C99 compliant and quite robust to edge cases. The 
javadoc needs a second pass and then an internal rearrangement of the code 
layout. I’ve left this until last so that the git change history is clear. But 
the methods and API are done.

Then there is the implementation of ComplexList for storing and working with 
many complex numbers. This would be a replacement for part of 
numbers.complex.stream.ComplexUtils. The question is should this part of the 
API be established before any release? If a beta then we can remove redundant 
methods from ComplexUtils later.

I would not include the "commons-numbers-complex-streams" module
(IIRC you mentioned that for performance, "ComplexList" should be in
the same module as "Complex”).

Yes. I think a lot of the private methods in Complex would have to be promoted 
to package private for reuse so many of the functions could operate without 
having to actually create an instance of Complex.

That would be my suggestion. Since the beta release would be on a fork we can 
delete the module from the fork. Then it can be sanitised in master when 
appropriate.


Regards,
Gilles


Alex

[1] https://issues.apache.org/jira/browse/NUMBERS-142# 
<https://issues.apache.org/jira/browse/NUMBERS-142#> 
<https://issues.apache.org/jira/browse/NUMBERS-142# 
<https://issues.apache.org/jira/browse/NUMBERS-142#>>



Best,
Gilles


[...]

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
<mailto:dev-unsubscr...@commons.apache.org>
For additional commands, e-mail: dev-h...@commons.apache.org 
<mailto: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: [numbers] Release?

[Rob Tompkins]

Yes you’re totally welcome to, and the directions are here: 
http://commons.apache.org/releases/index.html 
<http://commons.apache.org/releases/index.html>

Feel free to ask questions and I would suggest using the release plugin portion 
of the release preparation page. If there’s confusion (I would expect some 
obsolescence) on the page do make note of it, and I would be happy to update it 
as we see fit.

All the best,
-Rob

> On Mar 24, 2020, at 9:26 AM, Matt Juntunen  wrote:
> 
> Hello,
> 
> Am I able to perform this beta release of numbers now that I am a committer? 
> If so, how would I go about it?
> 
> Thanks,
> Matt
> 
> From: Matt Juntunen 
> Sent: Saturday, March 7, 2020 7:37 AM
> To: Alex Herbert ; Commons Developers List 
> 
> Subject: Re: [numbers] Release?
> 
> Hello,
> 
> Any progress here?
> 
> Regards,
> Matt
> 
> From: Alex Herbert 
> Sent: Friday, February 21, 2020 8:20 PM
> To: Commons Developers List 
> Subject: Re: [numbers] Release?
> 
> 
> 
>> On 22 Feb 2020, at 01:15, Gilles Sadowski  wrote:
>> 
>> Le sam. 22 févr. 2020 à 01:30, Alex Herbert > <mailto:alex.d.herb...@gmail.com>> a écrit :
>>> 
>>> 
>>> 
>>>> On 22 Feb 2020, at 00:29, Gilles Sadowski  wrote:
>>>> 
>>>> Hi.
>>>> 
>>>> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
>>>>  a écrit :
>>>>> 
>>>>> Are we waiting on anything for a numbers release?
>>>> 
>>>> I don't think so.
>>> 
>>> Are you talking about a beta release where the API is not yet frozen?
>> 
>> Yes.
>> 
>>> I’m still testing versions of LinearCombination. But from the discussion on 
>>> NUMBERS-142 [1] it seems the choice may be to just change the current class 
>>> to use a more precise method. It will be slower than the current method but 
>>> will have an ensured accuracy of 1 ULP. It will be much faster than 
>>> BigDecimal. All the testing implementations can go into the examples module 
>>> for reference.
>>> 
>>> I have 1 PR for Complex to add an internal version of Math.hypot 
>>> (NUMBERS-143). I’ll go over this soon and bring it in. The method is faster 
>>> and more accurate than Math.hypot.
>>> 
>>> I think Complex is ISO C99 compliant and quite robust to edge cases. The 
>>> javadoc needs a second pass and then an internal rearrangement of the code 
>>> layout. I’ve left this until last so that the git change history is clear. 
>>> But the methods and API are done.
>>> 
>>> Then there is the implementation of ComplexList for storing and working 
>>> with many complex numbers. This would be a replacement for part of 
>>> numbers.complex.stream.ComplexUtils. The question is should this part of 
>>> the API be established before any release? If a beta then we can remove 
>>> redundant methods from ComplexUtils later.
>> 
>> I would not include the "commons-numbers-complex-streams" module
>> (IIRC you mentioned that for performance, "ComplexList" should be in
>> the same module as "Complex”).
> 
> Yes. I think a lot of the private methods in Complex would have to be 
> promoted to package private for reuse so many of the functions could operate 
> without having to actually create an instance of Complex.
> 
> That would be my suggestion. Since the beta release would be on a fork we can 
> delete the module from the fork. Then it can be sanitised in master when 
> appropriate.
> 
>> 
>> Regards,
>> Gilles
>> 
>>> 
>>> Alex
>>> 
>>> [1] https://issues.apache.org/jira/browse/NUMBERS-142# 
>>> <https://issues.apache.org/jira/browse/NUMBERS-142#> 
>>> <https://issues.apache.org/jira/browse/NUMBERS-142# 
>>> <https://issues.apache.org/jira/browse/NUMBERS-142#>>
>>> 
>>> 
>>>> 
>>>> Best,
>>>> Gilles
>>>> 
>>>>> 
>>>>>> [...]
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
>> <mailto:dev-unsubscr...@commons.apache.org>
>> For additional commands, e-mail: dev-h...@commons.apache.org 
>> <mailto:dev-h...@commons.apache.org>

Re: [numbers] Release?

[Matt Juntunen]

Hello,

Am I able to perform this beta release of numbers now that I am a committer? If 
so, how would I go about it?

Thanks,
Matt

From: Matt Juntunen 
Sent: Saturday, March 7, 2020 7:37 AM
To: Alex Herbert ; Commons Developers List 

Subject: Re: [numbers] Release?

Hello,

Any progress here?

Regards,
Matt

From: Alex Herbert 
Sent: Friday, February 21, 2020 8:20 PM
To: Commons Developers List 
Subject: Re: [numbers] Release?



> On 22 Feb 2020, at 01:15, Gilles Sadowski  wrote:
>
> Le sam. 22 févr. 2020 à 01:30, Alex Herbert  <mailto:alex.d.herb...@gmail.com>> a écrit :
>>
>>
>>
>>> On 22 Feb 2020, at 00:29, Gilles Sadowski  wrote:
>>>
>>> Hi.
>>>
>>> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
>>>  a écrit :
>>>>
>>>> Are we waiting on anything for a numbers release?
>>>
>>> I don't think so.
>>
>> Are you talking about a beta release where the API is not yet frozen?
>
> Yes.
>
>> I’m still testing versions of LinearCombination. But from the discussion on 
>> NUMBERS-142 [1] it seems the choice may be to just change the current class 
>> to use a more precise method. It will be slower than the current method but 
>> will have an ensured accuracy of 1 ULP. It will be much faster than 
>> BigDecimal. All the testing implementations can go into the examples module 
>> for reference.
>>
>> I have 1 PR for Complex to add an internal version of Math.hypot 
>> (NUMBERS-143). I’ll go over this soon and bring it in. The method is faster 
>> and more accurate than Math.hypot.
>>
>> I think Complex is ISO C99 compliant and quite robust to edge cases. The 
>> javadoc needs a second pass and then an internal rearrangement of the code 
>> layout. I’ve left this until last so that the git change history is clear. 
>> But the methods and API are done.
>>
>> Then there is the implementation of ComplexList for storing and working with 
>> many complex numbers. This would be a replacement for part of 
>> numbers.complex.stream.ComplexUtils. The question is should this part of the 
>> API be established before any release? If a beta then we can remove 
>> redundant methods from ComplexUtils later.
>
> I would not include the "commons-numbers-complex-streams" module
> (IIRC you mentioned that for performance, "ComplexList" should be in
> the same module as "Complex”).

Yes. I think a lot of the private methods in Complex would have to be promoted 
to package private for reuse so many of the functions could operate without 
having to actually create an instance of Complex.

That would be my suggestion. Since the beta release would be on a fork we can 
delete the module from the fork. Then it can be sanitised in master when 
appropriate.

>
> Regards,
> Gilles
>
>>
>> Alex
>>
>> [1] https://issues.apache.org/jira/browse/NUMBERS-142# 
>> <https://issues.apache.org/jira/browse/NUMBERS-142#> 
>> <https://issues.apache.org/jira/browse/NUMBERS-142# 
>> <https://issues.apache.org/jira/browse/NUMBERS-142#>>
>>
>>
>>>
>>> Best,
>>> Gilles
>>>
>>>>
>>>>> [...]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
> <mailto:dev-unsubscr...@commons.apache.org>
> For additional commands, e-mail: dev-h...@commons.apache.org 
> <mailto:dev-h...@commons.apache.org>

Re: [numbers] Release?

[Matt Juntunen]

Hello,

Any progress here?

Regards,
Matt

From: Alex Herbert 
Sent: Friday, February 21, 2020 8:20 PM
To: Commons Developers List 
Subject: Re: [numbers] Release?



> On 22 Feb 2020, at 01:15, Gilles Sadowski  wrote:
>
> Le sam. 22 févr. 2020 à 01:30, Alex Herbert  <mailto:alex.d.herb...@gmail.com>> a écrit :
>>
>>
>>
>>> On 22 Feb 2020, at 00:29, Gilles Sadowski  wrote:
>>>
>>> Hi.
>>>
>>> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
>>>  a écrit :
>>>>
>>>> Are we waiting on anything for a numbers release?
>>>
>>> I don't think so.
>>
>> Are you talking about a beta release where the API is not yet frozen?
>
> Yes.
>
>> I’m still testing versions of LinearCombination. But from the discussion on 
>> NUMBERS-142 [1] it seems the choice may be to just change the current class 
>> to use a more precise method. It will be slower than the current method but 
>> will have an ensured accuracy of 1 ULP. It will be much faster than 
>> BigDecimal. All the testing implementations can go into the examples module 
>> for reference.
>>
>> I have 1 PR for Complex to add an internal version of Math.hypot 
>> (NUMBERS-143). I’ll go over this soon and bring it in. The method is faster 
>> and more accurate than Math.hypot.
>>
>> I think Complex is ISO C99 compliant and quite robust to edge cases. The 
>> javadoc needs a second pass and then an internal rearrangement of the code 
>> layout. I’ve left this until last so that the git change history is clear. 
>> But the methods and API are done.
>>
>> Then there is the implementation of ComplexList for storing and working with 
>> many complex numbers. This would be a replacement for part of 
>> numbers.complex.stream.ComplexUtils. The question is should this part of the 
>> API be established before any release? If a beta then we can remove 
>> redundant methods from ComplexUtils later.
>
> I would not include the "commons-numbers-complex-streams" module
> (IIRC you mentioned that for performance, "ComplexList" should be in
> the same module as "Complex”).

Yes. I think a lot of the private methods in Complex would have to be promoted 
to package private for reuse so many of the functions could operate without 
having to actually create an instance of Complex.

That would be my suggestion. Since the beta release would be on a fork we can 
delete the module from the fork. Then it can be sanitised in master when 
appropriate.

>
> Regards,
> Gilles
>
>>
>> Alex
>>
>> [1] https://issues.apache.org/jira/browse/NUMBERS-142# 
>> <https://issues.apache.org/jira/browse/NUMBERS-142#> 
>> <https://issues.apache.org/jira/browse/NUMBERS-142# 
>> <https://issues.apache.org/jira/browse/NUMBERS-142#>>
>>
>>
>>>
>>> Best,
>>> Gilles
>>>
>>>>
>>>>> [...]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
> <mailto:dev-unsubscr...@commons.apache.org>
> For additional commands, e-mail: dev-h...@commons.apache.org 
> <mailto:dev-h...@commons.apache.org>

Re: [numbers] Release?

[Alex Herbert]

> On 22 Feb 2020, at 01:15, Gilles Sadowski  wrote:
> 
> Le sam. 22 févr. 2020 à 01:30, Alex Herbert  <mailto:alex.d.herb...@gmail.com>> a écrit :
>> 
>> 
>> 
>>> On 22 Feb 2020, at 00:29, Gilles Sadowski  wrote:
>>> 
>>> Hi.
>>> 
>>> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
>>>  a écrit :
>>>> 
>>>> Are we waiting on anything for a numbers release?
>>> 
>>> I don't think so.
>> 
>> Are you talking about a beta release where the API is not yet frozen?
> 
> Yes.
> 
>> I’m still testing versions of LinearCombination. But from the discussion on 
>> NUMBERS-142 [1] it seems the choice may be to just change the current class 
>> to use a more precise method. It will be slower than the current method but 
>> will have an ensured accuracy of 1 ULP. It will be much faster than 
>> BigDecimal. All the testing implementations can go into the examples module 
>> for reference.
>> 
>> I have 1 PR for Complex to add an internal version of Math.hypot 
>> (NUMBERS-143). I’ll go over this soon and bring it in. The method is faster 
>> and more accurate than Math.hypot.
>> 
>> I think Complex is ISO C99 compliant and quite robust to edge cases. The 
>> javadoc needs a second pass and then an internal rearrangement of the code 
>> layout. I’ve left this until last so that the git change history is clear. 
>> But the methods and API are done.
>> 
>> Then there is the implementation of ComplexList for storing and working with 
>> many complex numbers. This would be a replacement for part of 
>> numbers.complex.stream.ComplexUtils. The question is should this part of the 
>> API be established before any release? If a beta then we can remove 
>> redundant methods from ComplexUtils later.
> 
> I would not include the "commons-numbers-complex-streams" module
> (IIRC you mentioned that for performance, "ComplexList" should be in
> the same module as "Complex”).

Yes. I think a lot of the private methods in Complex would have to be promoted 
to package private for reuse so many of the functions could operate without 
having to actually create an instance of Complex.

That would be my suggestion. Since the beta release would be on a fork we can 
delete the module from the fork. Then it can be sanitised in master when 
appropriate.

> 
> Regards,
> Gilles
> 
>> 
>> Alex
>> 
>> [1] https://issues.apache.org/jira/browse/NUMBERS-142# 
>> <https://issues.apache.org/jira/browse/NUMBERS-142#> 
>> <https://issues.apache.org/jira/browse/NUMBERS-142# 
>> <https://issues.apache.org/jira/browse/NUMBERS-142#>>
>> 
>> 
>>> 
>>> Best,
>>> Gilles
>>> 
>>>> 
>>>>> [...]
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org 
> <mailto:dev-unsubscr...@commons.apache.org>
> For additional commands, e-mail: dev-h...@commons.apache.org 
> <mailto:dev-h...@commons.apache.org>

Re: [numbers] Release?

[Gilles Sadowski]

Le sam. 22 févr. 2020 à 01:30, Alex Herbert  a écrit :
>
>
>
> > On 22 Feb 2020, at 00:29, Gilles Sadowski  wrote:
> >
> > Hi.
> >
> > Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
> >  a écrit :
> >>
> >> Are we waiting on anything for a numbers release?
> >
> > I don't think so.
>
> Are you talking about a beta release where the API is not yet frozen?

Yes.

> I’m still testing versions of LinearCombination. But from the discussion on 
> NUMBERS-142 [1] it seems the choice may be to just change the current class 
> to use a more precise method. It will be slower than the current method but 
> will have an ensured accuracy of 1 ULP. It will be much faster than 
> BigDecimal. All the testing implementations can go into the examples module 
> for reference.
>
> I have 1 PR for Complex to add an internal version of Math.hypot 
> (NUMBERS-143). I’ll go over this soon and bring it in. The method is faster 
> and more accurate than Math.hypot.
>
> I think Complex is ISO C99 compliant and quite robust to edge cases. The 
> javadoc needs a second pass and then an internal rearrangement of the code 
> layout. I’ve left this until last so that the git change history is clear. 
> But the methods and API are done.
>
> Then there is the implementation of ComplexList for storing and working with 
> many complex numbers. This would be a replacement for part of 
> numbers.complex.stream.ComplexUtils. The question is should this part of the 
> API be established before any release? If a beta then we can remove redundant 
> methods from ComplexUtils later.

I would not include the "commons-numbers-complex-streams" module
(IIRC you mentioned that for performance, "ComplexList" should be in
the same module as "Complex").

Regards,
Gilles

>
> Alex
>
> [1] https://issues.apache.org/jira/browse/NUMBERS-142# 
> <https://issues.apache.org/jira/browse/NUMBERS-142#>
>
>
> >
> > Best,
> > Gilles
> >
> >>
> >>> [...]

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

Re: [numbers] Release?

[Alex Herbert]

> On 22 Feb 2020, at 00:29, Gilles Sadowski  wrote:
> 
> Hi.
> 
> Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
>  a écrit :
>> 
>> Are we waiting on anything for a numbers release?
> 
> I don't think so.

Are you talking about a beta release where the API is not yet frozen?

I’m still testing versions of LinearCombination. But from the discussion on 
NUMBERS-142 [1] it seems the choice may be to just change the current class to 
use a more precise method. It will be slower than the current method but will 
have an ensured accuracy of 1 ULP. It will be much faster than BigDecimal. All 
the testing implementations can go into the examples module for reference.

I have 1 PR for Complex to add an internal version of Math.hypot (NUMBERS-143). 
I’ll go over this soon and bring it in. The method is faster and more accurate 
than Math.hypot.

I think Complex is ISO C99 compliant and quite robust to edge cases. The 
javadoc needs a second pass and then an internal rearrangement of the code 
layout. I’ve left this until last so that the git change history is clear. But 
the methods and API are done.

Then there is the implementation of ComplexList for storing and working with 
many complex numbers. This would be a replacement for part of 
numbers.complex.stream.ComplexUtils. The question is should this part of the 
API be established before any release? If a beta then we can remove redundant 
methods from ComplexUtils later.

Alex

[1] https://issues.apache.org/jira/browse/NUMBERS-142# 
<https://issues.apache.org/jira/browse/NUMBERS-142#>


> 
> Best,
> Gilles
> 
>> 
>>> [...]
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 

Re: [numbers] Release?

[Gilles Sadowski]

Hi.

Le ven. 21 févr. 2020 à 23:15, Matt Juntunen
 a écrit :
>
> Are we waiting on anything for a numbers release?

I don't think so.

Best,
Gilles

>
> > [...]

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

Re: [numbers] Release?

[Matt Juntunen]

Are we waiting on anything for a numbers release?

-Matt

From: Matt Juntunen 
Sent: Monday, February 17, 2020 10:36 PM
To: Commons Developers List 
Subject: Re: [numbers] Release?

Gilles,

> Anyways, +1 to making beta releases, even while still working
> on features that we want in version 1.0 "non-beta".

What are the next steps for this?

-Matt

From: Gilles Sadowski 
Sent: Thursday, February 13, 2020 10:27 AM
To: Commons Developers List 
Subject: Re: [numbers] Release?

Hi.

Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
 a écrit :
>
> Hello,
>
> Any chance we can get a release (beta or full) for commons-numbers?

Non-exhaustive check-list is here:
https://issues.apache.org/jira/browse/NUMBERS-25

All "crosses" to be changed to "checks"?

Anyways, +1 to making beta releases, even while still working
on features that we want in version 1.0 "non-beta".

> As I mentioned in another thread, commons-geometry is ready for a
> beta release

+1
And while doing so, it would be nice to prepare comparison
benchmarks with CM (v3.6.1).

> but we need commons-numbers to be released before we can do that.

Indeed.

Gilles

>
> Regards,
> Matt J

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

Re: [numbers] Release?

[Matt Juntunen]

Gilles,

> Anyways, +1 to making beta releases, even while still working
> on features that we want in version 1.0 "non-beta".

What are the next steps for this?

-Matt

From: Gilles Sadowski 
Sent: Thursday, February 13, 2020 10:27 AM
To: Commons Developers List 
Subject: Re: [numbers] Release?

Hi.

Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
 a écrit :
>
> Hello,
>
> Any chance we can get a release (beta or full) for commons-numbers?

Non-exhaustive check-list is here:
https://issues.apache.org/jira/browse/NUMBERS-25

All "crosses" to be changed to "checks"?

Anyways, +1 to making beta releases, even while still working
on features that we want in version 1.0 "non-beta".

> As I mentioned in another thread, commons-geometry is ready for a
> beta release

+1
And while doing so, it would be nice to prepare comparison
benchmarks with CM (v3.6.1).

> but we need commons-numbers to be released before we can do that.

Indeed.

Gilles

>
> Regards,
> Matt J

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

Re: [numbers] Release?

[Gilles Sadowski]

Hi.

Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
 a écrit :
>
> Hello,
>
> Any chance we can get a release (beta or full) for commons-numbers?

Non-exhaustive check-list is here:
https://issues.apache.org/jira/browse/NUMBERS-25

All "crosses" to be changed to "checks"?

Anyways, +1 to making beta releases, even while still working
on features that we want in version 1.0 "non-beta".

> As I mentioned in another thread, commons-geometry is ready for a
> beta release

+1
And while doing so, it would be nice to prepare comparison
benchmarks with CM (v3.6.1).

> but we need commons-numbers to be released before we can do that.

Indeed.

Gilles

>
> Regards,
> Matt J

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

Re: [numbers] Release?

[Matt Juntunen]

Hello,

NUMBERS-40 is now resolved. Are we ready for a beta release of commons-numbers?

-Matt

From: Gilles Sadowski 
Sent: Thursday, January 23, 2020 6:50 PM
To: Commons Developers List 
Subject: Re: [numbers] Release?

Hi.

2020-01-23 21:50 UTC+01:00, Matt Juntunen :
> Hello,
>
>> Currently, only one unresolved issue tagged for the first release.
>
> I had a look at it (NUMBERS-40) and it looks like all of the changes listed
> in the PR for the issue [1] are in place,

The report asked for reviewing a potential inconsistency in the
usage of exceptions; but PR #6 just changed the type thrown;
see my comment at the time:
https://issues.apache.org/jira/browse/NUMBERS-40?focusedCommentId=16041712=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16041712

> even though the PR was closed over
> 2 years ago. Is this issue still valid?

Yes.
IOW, the question, and report, is about whether usage is consistent
across all of "Commons Numbers".

Regards,
Gilles

>
> Regards,
> Matt
>
> [1] https://github.com/apache/commons-numbers/pull/6
> 
> From: Gilles Sadowski 
> Sent: Thursday, January 23, 2020 11:11 AM
> To: Commons Developers List 
> Subject: Re: [numbers] Release?
>
> Hi.
>
> Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
>  a écrit :
>>
>> Hello,
>>
>> Any chance we can get a release (beta or full) for commons-numbers?
>
> Currently, only one unresolved issue tagged for the first release.[1]
>
> Regards,
> Gilles
>
> [1]
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20NUMBERS%20AND%20fixVersion%20%3D%201.0%20AND%20statusCategory%20%3D%20new
>
>> As I mentioned in another thread, commons-geometry is ready for a beta
>> release but we need commons-numbers to be released before we can do that.
>>
>> Regards,
>> Matt J
>

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

Re: [numbers] Release?

[Gilles Sadowski]

Hi.

2020-01-23 21:50 UTC+01:00, Matt Juntunen :
> Hello,
>
>> Currently, only one unresolved issue tagged for the first release.
>
> I had a look at it (NUMBERS-40) and it looks like all of the changes listed
> in the PR for the issue [1] are in place,

The report asked for reviewing a potential inconsistency in the
usage of exceptions; but PR #6 just changed the type thrown;
see my comment at the time:
https://issues.apache.org/jira/browse/NUMBERS-40?focusedCommentId=16041712=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16041712

> even though the PR was closed over
> 2 years ago. Is this issue still valid?

Yes.
IOW, the question, and report, is about whether usage is consistent
across all of "Commons Numbers".

Regards,
Gilles

>
> Regards,
> Matt
>
> [1] https://github.com/apache/commons-numbers/pull/6
> 
> From: Gilles Sadowski 
> Sent: Thursday, January 23, 2020 11:11 AM
> To: Commons Developers List 
> Subject: Re: [numbers] Release?
>
> Hi.
>
> Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
>  a écrit :
>>
>> Hello,
>>
>> Any chance we can get a release (beta or full) for commons-numbers?
>
> Currently, only one unresolved issue tagged for the first release.[1]
>
> Regards,
> Gilles
>
> [1]
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20NUMBERS%20AND%20fixVersion%20%3D%201.0%20AND%20statusCategory%20%3D%20new
>
>> As I mentioned in another thread, commons-geometry is ready for a beta
>> release but we need commons-numbers to be released before we can do that.
>>
>> Regards,
>> Matt J
>

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

Re: [numbers] Release?

[Matt Juntunen]

Hello,

> Currently, only one unresolved issue tagged for the first release.

I had a look at it (NUMBERS-40) and it looks like all of the changes listed in 
the PR for the issue [1] are in place, even though the PR was closed over 2 
years ago. Is this issue still valid?

Regards,
Matt

[1] https://github.com/apache/commons-numbers/pull/6

From: Gilles Sadowski 
Sent: Thursday, January 23, 2020 11:11 AM
To: Commons Developers List 
Subject: Re: [numbers] Release?

Hi.

Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
 a écrit :
>
> Hello,
>
> Any chance we can get a release (beta or full) for commons-numbers?

Currently, only one unresolved issue tagged for the first release.[1]

Regards,
Gilles

[1] 
https://issues.apache.org/jira/issues/?jql=project%20%3D%20NUMBERS%20AND%20fixVersion%20%3D%201.0%20AND%20statusCategory%20%3D%20new

> As I mentioned in another thread, commons-geometry is ready for a beta 
> release but we need commons-numbers to be released before we can do that.
>
> Regards,
> Matt J

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

Re: [numbers] Release?

[Gilles Sadowski]

Hi.

Le jeu. 23 janv. 2020 à 15:04, Matt Juntunen
 a écrit :
>
> Hello,
>
> Any chance we can get a release (beta or full) for commons-numbers?

Currently, only one unresolved issue tagged for the first release.[1]

Regards,
Gilles

[1] 
https://issues.apache.org/jira/issues/?jql=project%20%3D%20NUMBERS%20AND%20fixVersion%20%3D%201.0%20AND%20statusCategory%20%3D%20new

> As I mentioned in another thread, commons-geometry is ready for a beta 
> release but we need commons-numbers to be released before we can do that.
>
> Regards,
> Matt J

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

[numbers] Release?

[Matt Juntunen]

Hello,

Any chance we can get a release (beta or full) for commons-numbers? As I 
mentioned in another thread, commons-geometry is ready for a beta release but 
we need commons-numbers to be released before we can do that.

Regards,
Matt J

Re: [Math][Numbers] Release(s)? What? When? Who?

[Gilles]

On Sat, 15 Apr 2017 09:23:02 -0400, Raymond DeCampo wrote:
On Sat, Apr 15, 2017 at 8:50 AM, Gilles 


wrote:


Hello.

On Sat, 15 Apr 2017 07:56:49 -0400, Raymond DeCampo wrote:

On Sun, Apr 9, 2017 at 2:20 PM, Gilles 


wrote:

Hi.


On Sun, 9 Apr 2017 14:01:54 -0400, Rob Tompkins wrote:

Has anyone created a Jira as a mechanism to track the decisioning

process of classifying the other Jiras in a project?



Not sure if it's what you mean, but there already were issues
opened for tracking progress towards a release.


Gilles, what are you referring to here?  Please forgive my lack of

familiarity with Jira.



I'm also not a JIRA power user; it is just a proposal to open a
regular issue as a "TO DO" list, akin to what has been done for
Commons RNG:
  https://issues.apache.org/jira/browse/RNG-6

And speaking of Jira, my Jira account does not seem to have proper

permissions to close out issues.



Does it occur for all (Commons) JIRA projects?



I checked with numbers, math and text and it happens with all of 
them.






Who should I contact to resolve that?




Gary (project's chair)? [IIRC, there has been some mix-up with
your Apache account(s).]


Yes, I had two Apache accounts for a bit, but that has been resolved 
and

there is only the one now.


Then there must be some global setting missing, as I don't see
anything in the JIRA for "Numbers" that would set you apart from
the other committers.

Regards,
Gilles


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

Re: [Math][Numbers] Release(s)? What? When? Who?

[Raymond DeCampo]

On Sat, Apr 15, 2017 at 8:50 AM, Gilles 
wrote:

> Hello.
>
> On Sat, 15 Apr 2017 07:56:49 -0400, Raymond DeCampo wrote:
>
>> On Sun, Apr 9, 2017 at 2:20 PM, Gilles 
>> wrote:
>>
>> Hi.
>>>
>>> On Sun, 9 Apr 2017 14:01:54 -0400, Rob Tompkins wrote:
>>>
>>> Has anyone created a Jira as a mechanism to track the decisioning
 process of classifying the other Jiras in a project?


>>> Not sure if it's what you mean, but there already were issues
>>> opened for tracking progress towards a release.
>>>
>>>
>>> Gilles, what are you referring to here?  Please forgive my lack of
>> familiarity with Jira.
>>
>
> I'm also not a JIRA power user; it is just a proposal to open a
> regular issue as a "TO DO" list, akin to what has been done for
> Commons RNG:
>   https://issues.apache.org/jira/browse/RNG-6
>
> And speaking of Jira, my Jira account does not seem to have proper
>> permissions to close out issues.
>>
>
> Does it occur for all (Commons) JIRA projects?


I checked with numbers, math and text and it happens with all of them.


>
>
> Who should I contact to resolve that?
>>
>
> Gary (project's chair)? [IIRC, there has been some mix-up with
> your Apache account(s).]
>
>
Yes, I had two Apache accounts for a bit, but that has been resolved and
there is only the one now.

Re: [Math][Numbers] Release(s)? What? When? Who?

[Gilles]

On Sat, 15 Apr 2017 07:56:49 -0400, Raymond DeCampo wrote:
On Sun, Apr 9, 2017 at 2:20 PM, Gilles  
wrote:



Hi.

On Sun, 9 Apr 2017 14:01:54 -0400, Rob Tompkins wrote:


Has anyone created a Jira as a mechanism to track the decisioning
process of classifying the other Jiras in a project?



Not sure if it's what you mean, but there already were issues
opened for tracking progress towards a release.



Gilles, what are you referring to here?  Please forgive my lack of
familiarity with Jira.

And speaking of Jira, my Jira account does not seem to have proper
permissions to close out issues.


When it's solved, please "resolve" the issues instead; "close"
is usually done post-release. [Actually, I do not know why it's
better that way!]

Thanks,
Gilles


Who should I contact to resolve that?



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

Re: [Math][Numbers] Release(s)? What? When? Who?

[Gilles]

Hello.

On Sat, 15 Apr 2017 07:56:49 -0400, Raymond DeCampo wrote:
On Sun, Apr 9, 2017 at 2:20 PM, Gilles  
wrote:



Hi.

On Sun, 9 Apr 2017 14:01:54 -0400, Rob Tompkins wrote:


Has anyone created a Jira as a mechanism to track the decisioning
process of classifying the other Jiras in a project?



Not sure if it's what you mean, but there already were issues
opened for tracking progress towards a release.



Gilles, what are you referring to here?  Please forgive my lack of
familiarity with Jira.


I'm also not a JIRA power user; it is just a proposal to open a
regular issue as a "TO DO" list, akin to what has been done for
Commons RNG:
  https://issues.apache.org/jira/browse/RNG-6


And speaking of Jira, my Jira account does not seem to have proper
permissions to close out issues.


Does it occur for all (Commons) JIRA projects?


Who should I contact to resolve that?


Gary (project's chair)? [IIRC, there has been some mix-up with
your Apache account(s).]


Regards,
Gilles


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

Re: [Math][Numbers] Release(s)? What? When? Who?

[Raymond DeCampo]

On Sun, Apr 9, 2017 at 2:20 PM, Gilles  wrote:

> Hi.
>
> On Sun, 9 Apr 2017 14:01:54 -0400, Rob Tompkins wrote:
>
>> Has anyone created a Jira as a mechanism to track the decisioning
>> process of classifying the other Jiras in a project?
>>
>
> Not sure if it's what you mean, but there already were issues
> opened for tracking progress towards a release.
>
>
Gilles, what are you referring to here?  Please forgive my lack of
familiarity with Jira.

And speaking of Jira, my Jira account does not seem to have proper
permissions to close out issues.  Who should I contact to resolve that?

Re: [Math][Numbers] Release(s)? What? When? Who?

[Raymond DeCampo]

On Fri, Apr 7, 2017 at 12:13 PM, Gilles 
wrote:

> Hello.
>
>
> IMO, it would make sense that the next release of Commons
> Math (v4.0) depend on "Commons Numbers" (v1.0 ?) and
> Commons RNG (v1.1).
>
> Could people who volunteered for moving/refactoring the
> codes provide some status information and expected roadmap
> for getting to a state where release of the existing modules
> could be considered?
>  * commons-numbers-core
> - Which other classes (namely from "o.a.c.math4.utils")
>   yet to add?
>  * commons-numbers-complex
> - Add "Complex" solvers (?)
>  * commons-numbers-fraction
> - Add "ContinuedFraction" (?)
>

Looks like a good match to me.


>  * commons-numbers-quaternion
>
> The purpose is of course to drop the corresponding CM packages.
>
> New modules to consider for Commons Numbers:
>  * commons-numbers-combinatorics
>  * commons-numbers-jdkmath (from "o.a.c.m.util.FastMath")
> - Or drop "FastMath" altogether?
>   Cf. https://issues.apache.org/jira/browse/MATH-740


My inclination would be to drop it based on the discussion in the
referenced issue


>
>  * commons-numbers-arrays (from "o.a.c.m.util.MathArrays")
>

Also DoubleArray and ResizableDoubleArray


>  * commons-numbers-primes (from "o.a.c.m.primes")
>

This looks like a natural fit for numbers.

Re: [Math][Numbers] Release(s)? What? When? Who?

[Gilles]

Hi.

On Sun, 9 Apr 2017 14:01:54 -0400, Rob Tompkins wrote:

Has anyone created a Jira as a mechanism to track the decisioning
process of classifying the other Jiras in a project?


Not sure if it's what you mean, but there already were issues
opened for tracking progress towards a release.

Gilles


Just curious,
because it seems more appropriate than having that discussion out 
here

on the mailing list.

Thoughts?

-Rob

On Apr 8, 2017, at 9:12 AM, Gilles  
wrote:


Hi Rob, and all.

[Your mail arrived a bit mangled with other posts.]


On Sat, 8 Apr 2017 08:05:07 -0400, Rob Tompkins wrote:
> [...]


You will have to pardon me Gilles, as I have, much like Gary, have 
been
quite busy of late. I suppose the main question here should be: of 
the 101
open, in-progress, or reopened, jiras, which most need to be in 
4.0. Can we
sort them into two categories, 4.0 and 4.X? Do you mind if I try to 
make
some headway in this area? I will continue to read through the 
issues to

see wha



[Seems there was something more you wanted to say.]

Whatever you can do to clean up (request for feedback from the issue
reporter, sort issues, ...) is welcome of course.

Let me be clearer (if I can): I do not (and cannot) request that
contributors spend more time than they have at their disposal.
But I would like to know whether the situation is here to stay, i.e.
whether committers have lost interest in helping with CM and related
stuff.

I recall that I had announced, now almost a year ago, that
1. I do not have the capacity to maintain CM all by myself, and that
  it was/is (IMHO) a disservice to current and future users to let 
the

  code rot,
2. a viable alternative existed (IMO): more focused components (for
  codes which active contributors could maintain).

AFAIR, the proposal was well accepted by all "new" committers (5 
people),

but not by the majority of PMC members (who spoke out).

Since then, no PMC member has significantly contributed to CM so as 
to
advance towards a future release of the component as is (in the 
"master"

branch).

I ask a simple and direct question to all PMC members: Is it now OK
to save the pieces of CM (so that each can be mended at its own 
pace,
waiting the necessary workforce to do so), or do you prefer that 
_all_
the code gets less and less relevant (due to bugs or outdated 
practice

and that the community disappears?

Thanks for your attention,
Gilles



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

Re: [Math][Numbers] Release(s)? What? When? Who?

[Rob Tompkins]

Has anyone created a Jira as a mechanism to track the decisioning process of 
classifying the other Jiras in a project? Just curious, because it seems more 
appropriate than having that discussion out here on the mailing list. 

Thoughts?

-Rob

> On Apr 8, 2017, at 9:12 AM, Gilles  wrote:
> 
> Hi Rob, and all.
> 
> [Your mail arrived a bit mangled with other posts.]
> 
>> On Sat, 8 Apr 2017 08:05:07 -0400, Rob Tompkins wrote:
>> > [...]
>> 
>> 
>> You will have to pardon me Gilles, as I have, much like Gary, have been
>> quite busy of late. I suppose the main question here should be: of the 101
>> open, in-progress, or reopened, jiras, which most need to be in 4.0. Can we
>> sort them into two categories, 4.0 and 4.X? Do you mind if I try to make
>> some headway in this area? I will continue to read through the issues to
>> see wha
>> 
> 
> [Seems there was something more you wanted to say.]
> 
> Whatever you can do to clean up (request for feedback from the issue
> reporter, sort issues, ...) is welcome of course.
> 
> Let me be clearer (if I can): I do not (and cannot) request that
> contributors spend more time than they have at their disposal.
> But I would like to know whether the situation is here to stay, i.e.
> whether committers have lost interest in helping with CM and related
> stuff.
> 
> I recall that I had announced, now almost a year ago, that
> 1. I do not have the capacity to maintain CM all by myself, and that
>   it was/is (IMHO) a disservice to current and future users to let the
>   code rot,
> 2. a viable alternative existed (IMO): more focused components (for
>   codes which active contributors could maintain).
> 
> AFAIR, the proposal was well accepted by all "new" committers (5 people),
> but not by the majority of PMC members (who spoke out).
> 
> Since then, no PMC member has significantly contributed to CM so as to
> advance towards a future release of the component as is (in the "master"
> branch).
> 
> I ask a simple and direct question to all PMC members: Is it now OK
> to save the pieces of CM (so that each can be mended at its own pace,
> waiting the necessary workforce to do so), or do you prefer that _all_
> the code gets less and less relevant (due to bugs or outdated practice
> and that the community disappears?
> 
> Thanks for your attention,
> Gilles
> 
> 
> 
> -
> 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][Numbers] Release(s)? What? When? Who?

[Rob Tompkins]

> On Apr 8, 2017, at 9:12 AM, Gilles  wrote:
> 
> Hi Rob, and all.
> 
> [Your mail arrived a bit mangled with other posts.]
> 
> On Sat, 8 Apr 2017 08:05:07 -0400, Rob Tompkins wrote:
>> > [...]
>> 
>> 
>> You will have to pardon me Gilles, as I have, much like Gary, have been
>> quite busy of late. I suppose the main question here should be: of the 101
>> open, in-progress, or reopened, jiras, which most need to be in 4.0. Can we
>> sort them into two categories, 4.0 and 4.X? Do you mind if I try to make
>> some headway in this area? I will continue to read through the issues to
>> see wha
>> 
> 
> [Seems there was something more you wanted to say.]
> 
> Whatever you can do to clean up (request for feedback from the issue
> reporter, sort issues, ...) is welcome of course.
> 
> Let me be clearer (if I can): I do not (and cannot) request that
> contributors spend more time than they have at their disposal.
> But I would like to know whether the situation is here to stay, i.e.
> whether committers have lost interest in helping with CM and related
> stuff.
> 

I am still quite interested in the matter at hand. My current plan is to try to 
triage those 101 Jiras out there. Then, regardless of direction, we can at 
least tackle the issues that are the most pressing first.

> I recall that I had announced, now almost a year ago, that
> 1. I do not have the capacity to maintain CM all by myself, and that
>   it was/is (IMHO) a disservice to current and future users to let the
>   code rot,
> 2. a viable alternative existed (IMO): more focused components (for
>   codes which active contributors could maintain).
> 
> AFAIR, the proposal was well accepted by all "new" committers (5 people),
> but not by the majority of PMC members (who spoke out).
> 
> Since then, no PMC member has significantly contributed to CM so as to
> advance towards a future release of the component as is (in the "master"
> branch).
> 
> I ask a simple and direct question to all PMC members: Is it now OK
> to save the pieces of CM (so that each can be mended at its own pace,
> waiting the necessary workforce to do so), or do you prefer that _all_
> the code gets less and less relevant (due to bugs or outdated practice
> and that the community disappears?
> 
> Thanks for your attention,
> Gilles
> 
> 
> 
> -
> 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][Numbers] Release(s)? What? When? Who?

[Gilles]

Hi Rob, and all.

[Your mail arrived a bit mangled with other posts.]

On Sat, 8 Apr 2017 08:05:07 -0400, Rob Tompkins wrote:

> [...]


You will have to pardon me Gilles, as I have, much like Gary, have 
been
quite busy of late. I suppose the main question here should be: of 
the 101
open, in-progress, or reopened, jiras, which most need to be in 4.0. 
Can we
sort them into two categories, 4.0 and 4.X? Do you mind if I try to 
make
some headway in this area? I will continue to read through the issues 
to

see wha



[Seems there was something more you wanted to say.]

Whatever you can do to clean up (request for feedback from the issue
reporter, sort issues, ...) is welcome of course.

Let me be clearer (if I can): I do not (and cannot) request that
contributors spend more time than they have at their disposal.
But I would like to know whether the situation is here to stay, i.e.
whether committers have lost interest in helping with CM and related
stuff.

I recall that I had announced, now almost a year ago, that
1. I do not have the capacity to maintain CM all by myself, and that
   it was/is (IMHO) a disservice to current and future users to let the
   code rot,
2. a viable alternative existed (IMO): more focused components (for
   codes which active contributors could maintain).

AFAIR, the proposal was well accepted by all "new" committers (5 
people),

but not by the majority of PMC members (who spoke out).

Since then, no PMC member has significantly contributed to CM so as to
advance towards a future release of the component as is (in the 
"master"

branch).

I ask a simple and direct question to all PMC members: Is it now OK
to save the pieces of CM (so that each can be mended at its own pace,
waiting the necessary workforce to do so), or do you prefer that _all_
the code gets less and less relevant (due to bugs or outdated practice
and that the community disappears?

Thanks for your attention,
Gilles



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

Re: [Math][Numbers] Release(s)? What? When? Who?

[Rob Tompkins]

On Apr 7, 2017, at 2:50 PM, Gary Gregory  wrote:

Hi Gilles,

My guess is that we experiencing a mix folks being busy and a lack of fresh
blood in Commons. I know I am busy ATM! I bet you must feel frustrated and
I am sorry about that. It does not help that there are different opinions
on how to organize items or not between Commons components. Speaking
personally, I do not have the bandwidth ATM to dig in Commons Math and
related code within and without that component. I hope others can chip in
in keeping this part of our community active.

Cheers,
Gary

On Fri, Apr 7, 2017 at 9:13 AM, Gilles  wrote:

Hello.


IMO, it would make sense that the next release of Commons
Math (v4.0) depend on "Commons Numbers" (v1.0 ?) and
Commons RNG (v1.1).

Could people who volunteered for moving/refactoring the
codes provide some status information and expected roadmap
for getting to a state where release of the existing modules
could be considered?
* commons-numbers-core
   - Which other classes (namely from "o.a.c.math4.utils")
 yet to add?
* commons-numbers-complex
   - Add "Complex" solvers (?)
* commons-numbers-fraction
   - Add "ContinuedFraction" (?)
* commons-numbers-quaternion

The purpose is of course to drop the corresponding CM packages.

New modules to consider for Commons Numbers:
* commons-numbers-combinatorics
* commons-numbers-jdkmath (from "o.a.c.m.util.FastMath")
   - Or drop "FastMath" altogether?
 Cf. https://issues.apache.org/jira/browse/MATH-740
* commons-numbers-arrays (from "o.a.c.m.util.MathArrays")
* commons-numbers-primes (from "o.a.c.m.primes")
Please comment.

Also, what is status of "Commons SigProc"?
If this new component would be released, then I guess that we
could safely drop package "o.a.c.math4.filter".


Regards,
Gilles

P.S. My last post about the CM's JIRA backlog did not elicit
much reaction.


You will have to pardon me Gilles, as I have, much like Gary, have been
quite busy of late. I suppose the main question here should be: of the 101
open, in-progress, or reopened, jiras, which most need to be in 4.0. Can we
sort them into two categories, 4.0 and 4.X? Do you mind if I try to make
some headway in this area? I will continue to read through the issues to
see wha

I'd like to know what the PMC members think
of that situation. Is the status quo (i.e. the image of CM
getting worse with each reported bug) satisfactory for the
PMC? [Gary, please include in the report a paragraph about
the state of the matter.]


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




-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [Math][Numbers] Release(s)? What? When? Who?

[Gary Gregory]

Hi Gilles,

My guess is that we experiencing a mix folks being busy and a lack of fresh
blood in Commons. I know I am busy ATM! I bet you must feel frustrated and
I am sorry about that. It does not help that there are different opinions
on how to organize items or not between Commons components. Speaking
personally, I do not have the bandwidth ATM to dig in Commons Math and
related code within and without that component. I hope others can chip in
in keeping this part of our community active.

Cheers,
Gary

On Fri, Apr 7, 2017 at 9:13 AM, Gilles  wrote:

> Hello.
>
>
> IMO, it would make sense that the next release of Commons
> Math (v4.0) depend on "Commons Numbers" (v1.0 ?) and
> Commons RNG (v1.1).
>
> Could people who volunteered for moving/refactoring the
> codes provide some status information and expected roadmap
> for getting to a state where release of the existing modules
> could be considered?
>  * commons-numbers-core
> - Which other classes (namely from "o.a.c.math4.utils")
>   yet to add?
>  * commons-numbers-complex
> - Add "Complex" solvers (?)
>  * commons-numbers-fraction
> - Add "ContinuedFraction" (?)
>  * commons-numbers-quaternion
>
> The purpose is of course to drop the corresponding CM packages.
>
> New modules to consider for Commons Numbers:
>  * commons-numbers-combinatorics
>  * commons-numbers-jdkmath (from "o.a.c.m.util.FastMath")
> - Or drop "FastMath" altogether?
>   Cf. https://issues.apache.org/jira/browse/MATH-740
>  * commons-numbers-arrays (from "o.a.c.m.util.MathArrays")
>  * commons-numbers-primes (from "o.a.c.m.primes")
> Please comment.
>
> Also, what is status of "Commons SigProc"?
> If this new component would be released, then I guess that we
> could safely drop package "o.a.c.math4.filter".
>
>
> Regards,
> Gilles
>
> P.S. My last post about the CM's JIRA backlog did not elicit
>  much reaction. I'd like to know what the PMC members think
>  of that situation. Is the status quo (i.e. the image of CM
>  getting worse with each reported bug) satisfactory for the
>  PMC? [Gary, please include in the report a paragraph about
>  the state of the matter.]
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition



JUnit in Action, Second Edition



Spring Batch in Action


Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[Math][Numbers] Release(s)? What? When? Who?

[Gilles]

Hello.


IMO, it would make sense that the next release of Commons
Math (v4.0) depend on "Commons Numbers" (v1.0 ?) and
Commons RNG (v1.1).

Could people who volunteered for moving/refactoring the
codes provide some status information and expected roadmap
for getting to a state where release of the existing modules
could be considered?
 * commons-numbers-core
- Which other classes (namely from "o.a.c.math4.utils")
  yet to add?
 * commons-numbers-complex
- Add "Complex" solvers (?)
 * commons-numbers-fraction
- Add "ContinuedFraction" (?)
 * commons-numbers-quaternion

The purpose is of course to drop the corresponding CM packages.

New modules to consider for Commons Numbers:
 * commons-numbers-combinatorics
 * commons-numbers-jdkmath (from "o.a.c.m.util.FastMath")
- Or drop "FastMath" altogether?
  Cf. https://issues.apache.org/jira/browse/MATH-740
 * commons-numbers-arrays (from "o.a.c.m.util.MathArrays")
 * commons-numbers-primes (from "o.a.c.m.primes")
Please comment.

Also, what is status of "Commons SigProc"?
If this new component would be released, then I guess that we
could safely drop package "o.a.c.math4.filter".


Regards,
Gilles

P.S. My last post about the CM's JIRA backlog did not elicit
 much reaction. I'd like to know what the PMC members think
 of that situation. Is the status quo (i.e. the image of CM
 getting worse with each reported bug) satisfactory for the
 PMC? [Gary, please include in the report a paragraph about
 the state of the matter.]


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