[math] new feature to allow infinite limits in numerical integration.

I've submitted a patch for the issue (see MATH-994). This will allow users to integrate functions with infinity as one of the bounds. Cheers, Ajo Fod.

Re: [VOTE] Commons Staging Plugin - move to proper from sandbox

-0 I don't think this sort of things belongs in Commons proper as a component. What we advertise, release and support from commons proper are general purpose libraries that developers can use in their own applications. This is what Commons was created for. While the staging plugin looks like a

Re: [CHAIN] Thoughts about o.a.c.chain2.Chain, o.a.c.chain2.Command and the base classes

Hi Simone, more meat as I expected, thats for sure. I will provide a patch for CHAIN-98tomorow. The patch will only cover the refactoring of CONTINUE and COMPLETED processing results. But, I do not understand how exceptions should be handled in thi

[VOTE] Release Apache Commons Digest Plugin 0.1 based on RC2

This is a vote to release Apache Commons Digest Plugin 0.1 based on RC2 This is the initial release of the digest plugin, which creates MD5 and SHA1 hashes for whatever files you specify. The code is not expected to be perfect in this release. So long as it is usable (and the release is valid) I'

Re: [VOTE] Commons Staging Plugin - move to proper from sandbox

On 21 June 2013 19:45, Benedikt Ritter wrote: > Hello Sebb, > > I very much appreciate your effort to ease the release process (although I've > never been RM). Thanks. > I'd like to see some tests in the plugin. The code should meet the same > quality requirements we put on other proper compon

Re: [VFS] Itch to implement a SFTP filesystem client using sshd

On Wed, Jun 19, 2013 at 3:12 AM, Julien Aymé wrote: > Hi everyone, > > I've used sshd from mina at work > (http://mina.apache.org/sshd-project/index.html), and I found the api > really attractive. > In sshd there is already a SFTP server implemented, but there is no > SFTP filesystem client suppo

Re: [VOTE] Commons Staging Plugin - move to proper from sandbox

Hello Sebb, I very much appreciate your effort to ease the release process (although I've never been RM). I'd like to see some tests in the plugin. The code should meet the same quality requirements we put on other proper components (although it is intended to be used only for releasing common

Re: [ALL] What is the correct process for promoting components from sandbox to proper (was: Re: svn commit: r1494980 - in /commons: proper/commons-gpg-plugin/ sandbox/commons-gpg-plugin/)

On 6/21/13 10:45 AM, luc wrote: > Le 2013-06-21 17:34, Ralph Goers a écrit : >> I prefer the distinct separation between sandbox and proper >> (although >> I've never understood why the word "proper" was chosen). > > I agree for two different reasons. > The first one was already given by Sebb: user

Re: [VOTE] Commons Staging Plugin - move to proper from sandbox

+1 Gary On Fri, Jun 21, 2013 at 10:06 AM, sebb wrote: > [I'm not sure a vote for this is really needed, but] > > I'd like to move the staging plugin from the sandbox to commons > proper, so it can be released for use by Commons. > > The component name is currently > > commons-staging-plugin >

Re: [ALL] What is the correct process for promoting components from sandbox to proper (was: Re: svn commit: r1494980 - in /commons: proper/commons-gpg-plugin/ sandbox/commons-gpg-plugin/)

Le 2013-06-21 17:34, Ralph Goers a écrit : I prefer the distinct separation between sandbox and proper (although I've never understood why the word "proper" was chosen). I agree for two different reasons. The first one was already given by Sebb: users expect commons proper to be mature and mai

Re: [VOTE] Commons Staging Plugin - move to proper from sandbox

Le 2013-06-21 16:06, sebb a écrit : [I'm not sure a vote for this is really needed, but] I'd like to move the staging plugin from the sandbox to commons proper, so it can be released for use by Commons. +1 The component name is currently commons-staging-plugin I propose to keep the same n

Re: [ALL] What is the correct process for promoting components from sandbox to proper (was: Re: svn commit: r1494980 - in /commons: proper/commons-gpg-plugin/ sandbox/commons-gpg-plugin/)

On 21 June 2013 16:34, Ralph Goers wrote: > I prefer the distinct separation between sandbox and proper (although I've > never understood why the word "proper" was chosen). +1 > As for moving components I would suggest starting a DISCUSS thread and then, > if appropriate, move to a vote thread

Re: [ALL] What is the correct process for promoting components from sandbox to proper (was: Re: svn commit: r1494980 - in /commons: proper/commons-gpg-plugin/ sandbox/commons-gpg-plugin/)

I prefer the distinct separation between sandbox and proper (although I've never understood why the word "proper" was chosen). As for moving components I would suggest starting a DISCUSS thread and then, if appropriate, move to a vote thread. Ralph On Jun 21, 2013, at 7:22 AM, Emmanuel Bourg

Re: [ALL] What is the correct process for promoting components from sandbox to proper (was: Re: svn commit: r1494980 - in /commons: proper/commons-gpg-plugin/ sandbox/commons-gpg-plugin/)

Le 21/06/2013 16:02, sebb a écrit : > Also, I don't think we should have code under proper that is not > likely to be supported going forward. > > Users have the expectation that code under proper is mature and supported. It's doesn't prevent announcing a component as experimental with a clear d

[VOTE] Commons Staging Plugin - move to proper from sandbox

[I'm not sure a vote for this is really needed, but] I'd like to move the staging plugin from the sandbox to commons proper, so it can be released for use by Commons. The component name is currently commons-staging-plugin I propose to keep the same name unless there are objections. The vote wi

Re: [ALL] What is the correct process for promoting components from sandbox to proper (was: Re: svn commit: r1494980 - in /commons: proper/commons-gpg-plugin/ sandbox/commons-gpg-plugin/)

On 21 June 2013 14:57, Emmanuel Bourg wrote: > Le 21/06/2013 15:45, sebb a écrit : > >> we want to be able to drop sandboxes easily. > > How would that make "dropping" an experimental component more difficult? It would have to be removed from the website navigation. Also, I don't think we should

Re: [ALL] What is the correct process for promoting components from sandbox to proper (was: Re: svn commit: r1494980 - in /commons: proper/commons-gpg-plugin/ sandbox/commons-gpg-plugin/)

Le 21/06/2013 15:45, sebb a écrit : > we want to be able to drop sandboxes easily. How would that make "dropping" an experimental component more difficult? > also sandboxes can be used by non-Commons committers Commit access could be open to all Apache committers on proper as well. I trust the

Re: [ALL] What is the correct process for promoting components from sandbox to proper (was: Re: svn commit: r1494980 - in /commons: proper/commons-gpg-plugin/ sandbox/commons-gpg-plugin/)

On 21 June 2013 14:36, Emmanuel Bourg wrote: > Le 21/06/2013 15:29, Benedikt Ritter a écrit : > >> we are unsure about the process of promoting a component from sandbox to >> proper. Can this be done by simply announcing it or has a vote to take >> place? How has this been done in the past? > > Wh

Re: Commons plugins

On 21 June 2013 14:35, Matt Benson wrote: > I'm not retroactively -1ing anything, but don't we typically have a formal > vote for moving any component from sandbox to proper? What was different > about these plugins? They are intended for use in Commons builds, much like Commons Parent and the C

Re: [ALL] What is the correct process for promoting components from sandbox to proper (was: Re: svn commit: r1494980 - in /commons: proper/commons-gpg-plugin/ sandbox/commons-gpg-plugin/)

Heh, I just added a similar question to the plugins thread. Happy to let this thread rule them all, as it were. Matt On Fri, Jun 21, 2013 at 8:29 AM, Benedikt Ritter wrote: > Hi, > > we are unsure about the process of promoting a component from sandbox to > proper. Can this be done by simply

Re: [ALL] What is the correct process for promoting components from sandbox to proper (was: Re: svn commit: r1494980 - in /commons: proper/commons-gpg-plugin/ sandbox/commons-gpg-plugin/)

On 21 June 2013 14:29, Benedikt Ritter wrote: > Hi, > > we are unsure about the process of promoting a component from sandbox to > proper. Can this be done by simply announcing it or has a vote to take > place? How has this been done in the past? I suspect the answer is - it depends. Is the soft

Re: [ALL] What is the correct process for promoting components from sandbox to proper (was: Re: svn commit: r1494980 - in /commons: proper/commons-gpg-plugin/ sandbox/commons-gpg-plugin/)

Le 21/06/2013 15:29, Benedikt Ritter a écrit : > we are unsure about the process of promoting a component from sandbox to > proper. Can this be done by simply announcing it or has a vote to take > place? How has this been done in the past? What about merging the sandbox with proper? That would be

Re: Commons plugins

I'm not retroactively -1ing anything, but don't we typically have a formal vote for moving any component from sandbox to proper? What was different about these plugins? Thanks, Matt On Thu, Jun 20, 2013 at 9:06 AM, sebb wrote: > On 20 June 2013 14:43, Gary Gregory wrote: > > Is there any tho

[ALL] What is the correct process for promoting components from sandbox to proper (was: Re: svn commit: r1494980 - in /commons: proper/commons-gpg-plugin/ sandbox/commons-gpg-plugin/)

Hi, we are unsure about the process of promoting a component from sandbox to proper. Can this be done by simply announcing it or has a vote to take place? How has this been done in the past? Regards, Benedikt 2013/6/21 sebb > On 21 June 2013 07:59, Benedikt Ritter wrote: > > 2013/6/20 Simone

[CANCEL][VOTE] Release commons-digest-plugin 1.0 based on RC2

As already advised - missing AL header. On 21 June 2013 09:54, sebb wrote: > This is a vote to release Apache Commons Digest Plugin based on RC2 > > This is the initial release of the digest plugin, which creates MD5 > and SHA1 hashes for whatever files you specify. > > The code is not expected t

Re: [VOTE] Release commons-digest-plugin 1.0 based on RC2

On Fri, Jun 21, 2013 at 8:51 AM, sebb wrote: > Yes, I thought I just did. > I thought we email a [CANCEL][VOTE] email when that happens to make it clear. Gary > On 21 June 2013 13:19, Gary Gregory wrote: > > So are your canceling this vote due to the header issue? > > > > Gary > > > > On Jun

Re: [VOTE] Release commons-digest-plugin 1.0 based on RC2

Yes, I thought I just did. On 21 June 2013 13:19, Gary Gregory wrote: > So are your canceling this vote due to the header issue? > > Gary > > On Jun 21, 2013, at 4:55, sebb wrote: > >> This is a vote to release Apache Commons Digest Plugin based on RC2 >> >> This is the initial release of the di

Re: [VOTE] Release commons-digest-plugin 1.0 based on RC2

So are your canceling this vote due to the header issue? Gary On Jun 21, 2013, at 4:55, sebb wrote: > This is a vote to release Apache Commons Digest Plugin based on RC2 > > This is the initial release of the digest plugin, which creates MD5 > and SHA1 hashes for whatever files you specify. > >

Re: [CHAIN] Thoughts about o.a.c.chain2.Chain, o.a.c.chain2.Command and the base classes

> I'm not sure if we need ABORTED. What is the difference between COMPLETE > and ABORTED from the PoV of the Chain? Chain defines an algorithm for > processing and I currently don't see how ABORTED fits in there. > OTOH I see some potential here: * COMPLETE: all chain commands have completed the

Re: [VOTE] Release commons-digest-plugin 1.0 based on RC2

Unfortunately I've just discovered that pom.xml does not have an AL header. Not sure how that happened; I'm fairly sure I copied it from an existing project ... Sorry, I should have checked the RAT report ... Also discovered that the download page was missing; that could have been fixed after rel

Re: [VOTE] Release commons-digest-plugin 1.0 based on RC2

+1 Emmanuel Le 21/06/2013 10:54, sebb a écrit : > This is a vote to release Apache Commons Digest Plugin based on RC2 > > This is the initial release of the digest plugin, which creates MD5 > and SHA1 hashes for whatever files you specify. > > The code is not expected to be perfect in this rele

[VOTE] Release commons-digest-plugin 1.0 based on RC2

This is a vote to release Apache Commons Digest Plugin based on RC2 This is the initial release of the digest plugin, which creates MD5 and SHA1 hashes for whatever files you specify. The code is not expected to be perfect in this release. So long as it is usable (and the release is valid) I'd li

Re: svn commit: r1494980 - in /commons: proper/commons-gpg-plugin/ sandbox/commons-gpg-plugin/

On 21 June 2013 07:59, Benedikt Ritter wrote: > 2013/6/20 Simone Tripodi > >> On Thu, Jun 20, 2013 at 4:06 PM, sebb wrote: >> > On 20 June 2013 14:48, Simone Tripodi wrote: >> >> Don't you think it would worth at least announcing it, before moving a >> >> component from sandbox to proper? >> >

Re: [CSV] remaining issues before 1.0

On 21 June 2013 07:54, Benedikt Ritter wrote: > Hi Gary, > > nice to see some activity in CSV again. We were talking about reverting > CSVFormat back to the old API that does not use the builder pattern, see > CSV-99[1]. > We still have 18 unresolved issues. I think we should go through all those