Re: [Statistics] Port codes from Commons Math

[Gilles]

Hi.

On Fri, 16 Mar 2018 23:12:38 +0530, Gimhana Nadeeshan wrote:

Hi devs,

Sorry for the delayed reply due to my academics.



If you want to start playing with the code, we could just begin
by having discussions here (on design) and on JIRA (for processing
minor issues) based on the current state of your repository.
[What's the link to look it up?]



Should I create my own repo and start code in there?[Not in the 
forked repo]


What's the difference?  IOW, someone else should answer. :-}

Actually it will be more helpful to me if someone [ @Gilles or @Eric 
] can

guide me more. Like, to give me some minor issues in the current
implementation to solve or as a new feature implementation and 
gradually we

can go for deeper


IMO, the top priority would be to release "Commons Numbers":
  http://commons.apache.org/proper/commons-numbers/

There are some blocking issues on JIRA:
  https://issues.apache.org/jira/projects/NUMBERS


and eventually I can go further my my own way.  Then I
can gradually familiar with the code and I think it is the most 
efficient

way to learn the design architecture.[I spent hours to understand the
current code basis and I felt that was not so efficient as I thought]


Refactoring the package "stat" is not straightforward...
However, to get to that, it would be useful to record your thoughts
as you browse through the code(s): what seems easy to port, what should
be changed/fixed, what you don't understand, and so on.



And if there is a format of Proposal regarding ASF ?


I don't think so.  This ML is the forum where project directions
are discussed.


If not what should I
mention in the proposal basically?


This can be a work in progress, I think (see above suggestions).

Best regards,
Gilles



Best Regards,




On 14 March 2018 at 19:07, Gilles  
wrote:



Hi.

On Tue, 13 Mar 2018 23:37:24 +0530, Gimhana Nadeeshan wrote:


Hello Devs,

Thanks Gilles and Eric for guidance.

I have cloned the Commons repos and forked the Common's Stat repo. 
Is it

possible to make pull requests to that repo to be reviewed?



That's certainly possible, but I'm afraid that it will become
quite unwieldy from my side if I have to delete/create branches
for every PR.

If you want to start playing with the code, we could just begin
by having discussions here (on design) and on JIRA (for processing
minor issues) based on the current state of your repository.
[What's the link to look it up?]

Or should I

follow a specific method?



I'll inquire about a more efficient method (than the above)...

By referring the API docs I got some idea of the separation of 
modules.


In the current Commons's stat repo there are some classes under the
package  distribution. I think those can be refactored using java 8 
in

build statistics functionalities. Please correct me if I wrong.



An example perhaps?

As Eric said separation of function and streaming implementations is 
good
idea as designing. (In my point of view, it means method 
overloading ->

Again correct me if I didn't understand your fact correctly)



?

And I will share my draft proposal here for your review soon.




OK.

Thanks again for your interest,
Gilles




Best Regards.

On 13 March 2018 at 20:50, Gilles  
wrote:


Hello.


On Tue, 13 Mar 2018 09:25:19 +0100, Eric Barnhill wrote:

On Tue, Mar 13, 2018 at 12:47 AM, Gilles 


wrote:



Where can we find the old code before port into new Commons 
components?



The code bases are managed by the "git" software; the whole 
history is

available:
  
https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=log


[I'd advise to "clone" the repositories on your local computer, 
and

use the command line tools.]




I believe you will want to clone the commons-math repositories, 
but then
develop your own "fork" of the commons-statistics repository. 
Gilles can

correct me if that is wrong.



Actually, I know only my workflow:
 $ git clone ...
 $ git branch ...
 $ git commit ...
 $ git push

:-}

I didn't find it very easy to cooperate with developers who
fork on GitHub and submit PRs.
I've now found the "git" command that creates a branch from
a PR, but it would be so much more comfortable to just switch
directory and do "git pull".

In the context of GSoC, would it be possible to grant some
privilege to non-committers so that they can update a selected
"git" repository?
If not, what is the next easiest way to share a "common space"
(aka "sandbox") from which it would be easy to copy reviewed
bits over to the official source repository?


As


you mentioned it will be a good approach to redesign process.



You don't necessarily need to analyze how the code was before

the port/refactoring; looking at how it is now is sufficient,
unless you suspect that something is wrong now and might have
been better before. ;-)


In particular, the statistics library was designed before Java 
8. Java

8

Re: [lang] Todo utility class

[Matt Benson]

I also don't think it belongs in a testing module. OTOH, I appreciate the
desire not to have such hang around in finished code. I think I might
create a dedicated project around this (elsewhere) with a Maven plugin to
provide safeguards around unfinished uses of Todo.

Thanks for considering this,
Matt

On Mar 16, 2018 6:09 AM, "Gilles"  wrote:

> On Fri, 16 Mar 2018 00:35:24 -0700, Bindul Bhowmik wrote:
>
>> On Thu, Mar 15, 2018 at 4:05 PM, Gilles 
>> wrote:
>>
>>> Hi.
>>>
>>> On Wed, 14 Mar 2018 16:51:43 -0500, Matt Benson wrote:
>>>

 I have often thought about creating a utility class that allows me to
 write
 skeletal code that still compiles but will remind me to go back and
 finish
 it. This is a weird meta area of programming, but here are some basic
 usage
 examples:

 Foo foo = Todo.todo(); //returns null
 Bar bar = Todo.todo(THROWING_EXCEPTION); //throws
 NotImplementedException
 Baz baz = Todo.todo(RETURNING_NULL, "create a Baz"); //returns null and
 prints a message to System.err

 I would also think it a good (if odd) idea to make the whole class
 deprecated so that its use is flagged in tools, etc.

 Does the community think this code would be suited to the commons-lang
 component?

>>>
>>>
>>> Perhaps "Commons Testing".
>>> IIUC, such calls are not meant to appear in released code.
>>>
>>
>> I would recommend against commons testing. i would assume that
>> component would be a dependency with a test scope in most projects,
>> making it impossible to use it in the main code.
>>
>
> That is the feature: when about to release, all "Commons Testing"
> modules must be in "test" scope, and if they are used in "main",
> compilation will fail.
> In development, "main" would depend on "Commons Testing" to allow
> usage of "Todo".
>
> Gilles
>
> Regards,
>> Bindul
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Statistics] Port codes from Commons Math

[Gimhana Nadeeshan]

Hi devs,

Sorry for the delayed reply due to my academics.


> If you want to start playing with the code, we could just begin
> by having discussions here (on design) and on JIRA (for processing
> minor issues) based on the current state of your repository.
> [What's the link to look it up?]
>

Should I create my own repo and start code in there?[Not in the forked repo]

Actually it will be more helpful to me if someone [ @Gilles or @Eric ] can
guide me more. Like, to give me some minor issues in the current
implementation to solve or as a new feature implementation and gradually we
can go for deeper and eventually I can go further my my own way.  Then I
can gradually familiar with the code and I think it is the most efficient
way to learn the design architecture.[I spent hours to understand the
current code basis and I felt that was not so efficient as I thought]

And if there is a format of Proposal regarding ASF ? If not what should I
mention in the proposal basically?

Best Regards,




On 14 March 2018 at 19:07, Gilles  wrote:

> Hi.
>
> On Tue, 13 Mar 2018 23:37:24 +0530, Gimhana Nadeeshan wrote:
>
>> Hello Devs,
>>
>> Thanks Gilles and Eric for guidance.
>>
>> I have cloned the Commons repos and forked the Common's Stat repo. Is it
>> possible to make pull requests to that repo to be reviewed?
>>
>
> That's certainly possible, but I'm afraid that it will become
> quite unwieldy from my side if I have to delete/create branches
> for every PR.
>
> If you want to start playing with the code, we could just begin
> by having discussions here (on design) and on JIRA (for processing
> minor issues) based on the current state of your repository.
> [What's the link to look it up?]
>
> Or should I
>> follow a specific method?
>>
>
> I'll inquire about a more efficient method (than the above)...
>
> By referring the API docs I got some idea of the separation of modules.
>>
>> In the current Commons's stat repo there are some classes under the
>> package  distribution. I think those can be refactored using java 8 in
>> build statistics functionalities. Please correct me if I wrong.
>>
>
> An example perhaps?
>
> As Eric said separation of function and streaming implementations is good
>> idea as designing. (In my point of view, it means method overloading ->
>> Again correct me if I didn't understand your fact correctly)
>>
>
> ?
>
> And I will share my draft proposal here for your review soon.
>>
>
> OK.
>
> Thanks again for your interest,
> Gilles
>
>
>
>> Best Regards.
>>
>> On 13 March 2018 at 20:50, Gilles  wrote:
>>
>> Hello.
>>>
>>> On Tue, 13 Mar 2018 09:25:19 +0100, Eric Barnhill wrote:
>>>
>>> On Tue, Mar 13, 2018 at 12:47 AM, Gilles 
 wrote:



> Where can we find the old code before port into new Commons components?
>>
>>
>> The code bases are managed by the "git" software; the whole history is
> available:
>   https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=log
>
> [I'd advise to "clone" the repositories on your local computer, and
> use the command line tools.]
>
>

 I believe you will want to clone the commons-math repositories, but then
 develop your own "fork" of the commons-statistics repository. Gilles can
 correct me if that is wrong.


>>> Actually, I know only my workflow:
>>>  $ git clone ...
>>>  $ git branch ...
>>>  $ git commit ...
>>>  $ git push
>>>
>>> :-}
>>>
>>> I didn't find it very easy to cooperate with developers who
>>> fork on GitHub and submit PRs.
>>> I've now found the "git" command that creates a branch from
>>> a PR, but it would be so much more comfortable to just switch
>>> directory and do "git pull".
>>>
>>> In the context of GSoC, would it be possible to grant some
>>> privilege to non-committers so that they can update a selected
>>> "git" repository?
>>> If not, what is the next easiest way to share a "common space"
>>> (aka "sandbox") from which it would be easy to copy reviewed
>>> bits over to the official source repository?
>>>
>>>
>>> As
>
> you mentioned it will be a good approach to redesign process.
>>
>>
>> You don't necessarily need to analyze how the code was before
> the port/refactoring; looking at how it is now is sufficient,
> unless you suspect that something is wrong now and might have
> been better before. ;-)
>
>
> In particular, the statistics library was designed before Java 8. Java
 8
 however has provided both efficient programming strategies for these
 statistical methods (in the form of lambdas and streams) as well as some
 built-in methods providing summary statistics functions (see discussion
 at
 http://markmail.org/message/7t2mjaprsuvb3waj).


>>> Very good point, indeed.
>>> IMO, the new component should be targeted Java 8.
>>> Even Java 9 (enforcing modularity with 

[VOTE] Release Commons Text 1.3 based on RC1

[Rob Tompkins]

Hello all,

This is a [VOTE] for releasing Apache Commons Text 1.3 (from RC1).

Tag name:
   commons-text-1.3-RC1 (signature can be checked from git using 'git tag
-v')

Tag URL:
   
https://git-wip-us.apache.org/repos/asf?p=commons-text.git;a=tag;h=6e7a377e76bc7e34c286b5c5ee0433f00dc0d358

Commit ID the tag points at:
4ac48357180c9222f032dd8b055d90e1192e4a47

Site Zip:
   https://dist.apache.org/repos/dist/dev/commons/text/site.zip

Distribution files (committed at revision 25771):
   https://dist.apache.org/repos/dist/dev/commons/text/

Distribution files hashes (SHA1):
   commons-text-1.3-bin.tar.gz
   (SHA: 992637a7dcd53bdfc7831f3dfba171b998119e10)
   commons-text-1.3-bin.zip
   (SHA1: 6f4c8785d57f6af21fe08218e7d82ce5404c291c)
   commons-text-1.3-src.tar.gz
   (SHA1: 987bd384cb11bb5f52ddf5c866058faa6a00a298)
   commons-text-1.3-src.zip
   (SHA1: f234bbb3d0816800d4f7b997b65edbbc3c66c87c)

These are the Maven artifacts and their hashes:
   commons-text-1.3-javadoc.jar
   (SHA1: 8e170d7068f08823c0ad208214a48506f2950cbc)
   commons-text-1.3-sources.jar
   (SHA1: 9c51853f855aca4ea31785f30385e980a58eaf4b)
   commons-text-1.3-test-sources.jar
   (SHA1: d8f817cae41c3664ed89933e137f007a8e0f2c7b)
   commons-text-1.3-tests.jar
   (SHA1: 97d5a4ea56febf105f85cd6783a9dd8492d880c2)
   commons-text-1.3.jar
   (SHA1: 9abf61708a66ab5e55f6169a200dbfc584b546d9)
   commons-text-1.3.pom
   (SHA1: 319d278bae93adc3f5b5e8408a90fd2d98ce75f7)

KEYS file to check signatures:
   http://www.apache.org/dist/commons/KEYS

Maven artifacts:
   https://repository.apache.org/content/repositories/orgapachecommons-1319

Please select one of the following options[1]:
  [ ] +1 Release it.
  [ ] +0 Go ahead; I don't care.
  [ ] -0 There are a few minor glitches: ...
  [ ] -1 No, do not release it because ...

This vote will be open at least 72 hours, i.e. until 
2018-03-19T16:00:00Z
(this is UTC time).


Cheers,
-Rob

[1] http://apache.org/foundation/voting.html
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [jira] [Created] (COMMONSSITE-107) [release-plugin] Adding incorrect RELEASE-NOTES.txt file/directory to scm.

[Rob Tompkins]

This doesn’t preclude anyone from using commons-parent 45, as the 
commons-release-plugin is disabled by default. Further it can be used in 
staging, you just manually have to commit the files to the staging distribution 
location by running an “svn commit” from “./target/commons-release-plugin/scm”.

I will finish the commons-text, commons-rng, and commons-validator releases and 
then go back and work on another version of the commons-releas-plugin and 
commons-parent.

Cheers,
-Rob

> On Mar 16, 2018, at 11:17 AM, Rob Tompkins (JIRA)  wrote:
> 
> Rob Tompkins created COMMONSSITE-107:
> 
> 
> Summary: [release-plugin] Adding incorrect RELEASE-NOTES.txt 
> file/directory to scm.
> Key: COMMONSSITE-107
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-107
> Project: Commons All
>  Issue Type: Bug
>  Components: Commons Release Plugin
>Affects Versions: 1.1
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
> Fix For: 1.2
> 
> 
> When attempting to commit the releases, the {{commons-release-plugin}} 
> attempts to add {{./RELEASE-NOTES.txt} to the staging repo (which is outside 
> the svn directory structure) as opposed to the RELEASE-NOTES in 
> {{./target/commons-release-plugin/scm/RELEASE-NOTES.txt}}.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)


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

Re: [lang] Todo utility class

[Gilles]

On Fri, 16 Mar 2018 00:35:24 -0700, Bindul Bhowmik wrote:
On Thu, Mar 15, 2018 at 4:05 PM, Gilles 
 wrote:

Hi.

On Wed, 14 Mar 2018 16:51:43 -0500, Matt Benson wrote:


I have often thought about creating a utility class that allows me 
to

write
skeletal code that still compiles but will remind me to go back and 
finish
it. This is a weird meta area of programming, but here are some 
basic

usage
examples:

Foo foo = Todo.todo(); //returns null
Bar bar = Todo.todo(THROWING_EXCEPTION); //throws 
NotImplementedException
Baz baz = Todo.todo(RETURNING_NULL, "create a Baz"); //returns null 
and

prints a message to System.err

I would also think it a good (if odd) idea to make the whole class
deprecated so that its use is flagged in tools, etc.

Does the community think this code would be suited to the 
commons-lang

component?



Perhaps "Commons Testing".
IIUC, such calls are not meant to appear in released code.


I would recommend against commons testing. i would assume that
component would be a dependency with a test scope in most projects,
making it impossible to use it in the main code.


That is the feature: when about to release, all "Commons Testing"
modules must be in "test" scope, and if they are used in "main",
compilation will fail.
In development, "main" would depend on "Commons Testing" to allow
usage of "Todo".

Gilles


Regards,
Bindul




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

[CVE-2018-1324] Apache Commons Compress denial of service vulnerability

[Stefan Bodewig]

CVE-2018-1324: Apache Commons Compress denial of service vulnerability

Severity: Low

Vendor:
The Apache Software Foundation

Versions Affected:
Apache Commons Compress 1.11 to 1.15

Description:
A specially crafted ZIP archive can be used to cause an infinite loop
inside of Compress' extra field parser used by the ZipFile and
ZipArchiveInputStream classes.  This can be used to mount a denial of
service attack against services that use Compress' zip package.

Mitigation:
Commons Compress users should upgrade to 1.16 or later

Credit:
This issue was discovered by Luis Filipe Nassif.

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

Re: [lang] Todo utility class

[Bindul Bhowmik]

On Thu, Mar 15, 2018 at 4:05 PM, Gilles  wrote:
> Hi.
>
> On Wed, 14 Mar 2018 16:51:43 -0500, Matt Benson wrote:
>>
>> I have often thought about creating a utility class that allows me to
>> write
>> skeletal code that still compiles but will remind me to go back and finish
>> it. This is a weird meta area of programming, but here are some basic
>> usage
>> examples:
>>
>> Foo foo = Todo.todo(); //returns null
>> Bar bar = Todo.todo(THROWING_EXCEPTION); //throws NotImplementedException
>> Baz baz = Todo.todo(RETURNING_NULL, "create a Baz"); //returns null and
>> prints a message to System.err
>>
>> I would also think it a good (if odd) idea to make the whole class
>> deprecated so that its use is flagged in tools, etc.
>>
>> Does the community think this code would be suited to the commons-lang
>> component?
>
>
> Perhaps "Commons Testing".
> IIUC, such calls are not meant to appear in released code.

I would recommend against commons testing. i would assume that
component would be a dependency with a test scope in most projects,
making it impossible to use it in the main code.

Regards,
Bindul

>
> Regards,
> Gilles
>
>>
>> Matt
>
>
>
> -
> 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