date:20141218

Hi Reto,

2014-12-17 16:23 GMT+01:00 Reto Gmür r...@apache.org:

Hi,

This sounds like a great occasion to publish a revised version of the core
RDF libraries in clerezza as Commons RDF.

This has been the topic of several discussions already. The Clerezza RDF
libraries are strictly based on the RDF concepts and does not introduce
auxiliary concepts (like BNode labels) that narrow the field in which the
library is useful. Compared with the APIs provided by triple stores the
Clerezza API can thus more broadly be used for use cases benefiting from
the RDF model.

We had a similar proposal a while ago [1]. Is the Clerezza RDF library
related to this proposal? In the end the people around
https://github.com/commons-rdf/commons-rdf decided not to bring their code
to Apache Commons, because they wanted to use github for development and
discussions. They already requested the commons-rdf git repository from
infra, which is now unused [2]. So if you want to bring your RDF library to
commons, we can use that repo, I guess... I can help you with bootstraping
the component and bring up a website.

I see two major TODOs:
- Renaming: The current naming puts great emphasis on technical correctness
at the expenses of matching the colloquial use of the terms. The API should
be simplified to have Graphs and ImmutableGraphs rather than
TripleCollections, Graphs and MGraphs [1].
- RDF 1.1 Adaptation: the identity criteria must be redefined and probably
the class structure adapted for the identity of no language plain literals
and xsd-string typed literals

Regards,
Benedikt

[1] http://markmail.org/message/dtvy7mpm7gd7kvdw
[2] http://git.apache.org/

Cheers,
Reto

http://mail-archives.apache.org/mod_mbox/clerezza-dev/201406.mbox/%3ccalvhuewd_qyqlaans6oevvnr1ndzev9fssro0s6kj2vea41...@mail.gmail.com%3E
-- Forwarded message --
From: Benedikt Ritter brit...@apache.org
Date: Mon, Dec 15, 2014 at 4:05 PM
Subject: [ANNOUNCEMENT] Apache Commons grants write access to all ASF
committers
To: committ...@apache.org, Commons Developers List dev@commons.apache.org

Dear fellow committers,

The Apache Commons Team is pleased to announce that write access to the
Apache Commons Subversion and Git repositories has been granted to all ASF
committers.

Apache Commons is an Apache project focused on all aspects of reusable Java
components. As such, the components maintained by the Apache Commons
project
may be of interest to a variety of other Apache projects.

The Apache Commons community would like to invite you to share and maintain
useful code.

While Apache Commons is a Commit-Then-Review community, we would consider
it polite and helpful for contributors to announce their intentions and
plans on the dev mailing list [1] before committing code.

Have fun,

Benedikt Ritter,
on behalf of the Apache Commons Community

[1] http://commons.apache.org/mail-lists.html

--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

[DISCUSS] Jira karma for ASF committers? (Was: Re: [ANNOUNCEMENT] Apache Commons grants write access to all ASF committers)

Hi Adrian,

2014-12-18 3:47 GMT+01:00 Adrian Crum adrian.c...@sandglass-software.com:

 The challenge will be to keep Jira up-to-date. I would like to wrap up
 some Jira issues too, but ASF committers do not have edit permissions in
 Commons Jira.


You're bringing up a valid point here... If ASF committers can change the
code/fix bugs/implement new features, they should be able to modify the
corresponding jira tickets.

Benedikt



 Adrian Crum
 Sandglass Software
 www.sandglass-software.com


 On 12/18/2014 2:42 AM, Carl Hall wrote:

 Very cool!  I've been digging through the JIRA tickets for dbutils.  I
 would like to help clear those out and add some new things to the library.
 I'll be sure to send details to the list as things come up.

 On Mon, Dec 15, 2014 at 8:05 AM, Benedikt Ritter brit...@apache.org
 wrote:


 Dear fellow committers,

 The Apache Commons Team is pleased to announce that write access to the
 Apache Commons Subversion and Git repositories has been granted to all
 ASF
 committers.

 Apache Commons is an Apache project focused on all aspects of reusable
 Java
 components. As such, the components maintained by the Apache Commons
 project
 may be of interest to a variety of other Apache projects.

 The Apache Commons community would like to invite you to share and
 maintain
 useful code.

 While Apache Commons is a Commit-Then-Review community, we would consider
 it polite and helpful for contributors to announce their intentions and
 plans on the dev mailing list [1] before committing code.


 Have fun,

 Benedikt Ritter,
 on behalf of the Apache Commons Community

 [1] http://commons.apache.org/mail-lists.html

 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter



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



-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: svn commit: r1646312 - /commons/sandbox/rdf/

Hi Reto,

see my comment on the other thread. We can use git://
git.apache.org/commons-rdf.git if you like. Let me know when you're ready
to publish a website for this component.

Benedikt

2014-12-17 20:15 GMT+01:00 r...@apache.org:

 Author: reto
 Date: Wed Dec 17 19:15:22 2014
 New Revision: 1646312

 URL: http://svn.apache.org/r1646312
 Log:
 COMMONSSITE-80: initial sandbox from commons-rdf

 Added:
 commons/sandbox/rdf/



-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: svn commit: r1645502 - /commons/cms-site/trunk/content/xdoc/mail-lists.xml

2014-12-14 20:16 GMT+01:00 brit...@apache.org:

 Author: britter
 Date: Sun Dec 14 19:16:56 2014
 New Revision: 1645502

 URL: http://svn.apache.org/r1645502
 Log:
 Add commons notifications list to the list of mailing lists

 Modified:
 commons/cms-site/trunk/content/xdoc/mail-lists.xml

 Modified: commons/cms-site/trunk/content/xdoc/mail-lists.xml
 URL:
 http://svn.apache.org/viewvc/commons/cms-site/trunk/content/xdoc/mail-lists.xml?rev=1645502r1=1645501r2=1645502view=diff

 ==
 --- commons/cms-site/trunk/content/xdoc/mail-lists.xml (original)
 +++ commons/cms-site/trunk/content/xdoc/mail-lists.xml Sun Dec 14 19:16:56
 2014
 @@ -190,6 +190,30 @@
/td
  /tr

 +tr
 +  td
 +bCommons Notifications List/b
 +br /br /
 +Only for e-mails automatically generated by the a href=
 https://builds.apache.org/;CI systems/a.


Reading sebb's comments again, I think this is not correct. Can anybody
update this so it matches the actual intend of the ML?

TIA!


 +br /br /
 +  /td
 +  td
 +a href=mailto:notifications-subscr...@commons.apache.org
 Subscribe/a
 +  /td
 +  td
 +a href=mailto:notifications-unsubscr...@commons.apache.org
 Unsubscribe/a
 +  /td
 +  tdiread only/i/td
 +  td
 +a href=
 http://mail-archives.apache.org/mod_mbox/commons-notifications/;
 mail-archives.apache.org/a
 +  /td
 +  td
 +a href=
 http://markmail.org/list/org.apache.commons.notifications/;markmail.org
 /a
 +br/br
 +a href=
 http://www.mail-archive.com/notifications@commons.apache.org/;
 www.mail-archive.com/a
 +  /td
 +/tr
 +
/tbody
  /table
/section




-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [1/4] [math] Added Bessel functions of the first kind, based on NetLib implementation.

On 17 December 2014 at 10:50, Luc Maisonobe l...@spaceroots.org wrote:
 Hi Sebb,

 Le 17/12/2014 02:21, sebb a écrit :
 On 17 December 2014 at 00:01, Phil Steitz phil.ste...@gmail.com wrote:
 On 12/16/14 1:51 PM, sebb wrote:
 On 16 December 2014 at 08:58, luc l...@spaceroots.org wrote:
 Hi Phil,

 Le 2014-12-16 00:49, pste...@apache.org a écrit :
 Repository: commons-math
 Updated Branches:
   refs/heads/master 809f0f89c - 540aa2e7e


 Added Bessel functions of the first kind, based on NetLib implementation.

 JIRA: MATH-1066
 Based on patch provided by Brian Wignall


 Project: http://git-wip-us.apache.org/repos/asf/commons-math/repo
 Commit:
 http://git-wip-us.apache.org/repos/asf/commons-math/commit/f80f5777
 Tree: http://git-wip-us.apache.org/repos/asf/commons-math/tree/f80f5777
 Diff: http://git-wip-us.apache.org/repos/asf/commons-math/diff/f80f5777

 Branch: refs/heads/master
 Commit: f80f577748c0dbde45d24654247a82a7121d456c
 Parents: 59fe593
 Author: Phil Steitz phil.ste...@gmail.com
 Authored: Mon Dec 15 13:48:07 2014 -0700
 Committer: Phil Steitz phil.ste...@gmail.com
 Committed: Mon Dec 15 13:48:07 2014 -0700

 --
  findbugs-exclude-filter.xml |   7 +
  src/changes/changes.xml |   3 +
  .../apache/commons/math3/special/BesselJ.java   | 649 
  .../commons/math3/special/BesselJTest.java  | 777 
 +++
  4 files changed, 1436 insertions(+)
 --

 I think the NOTICE and LICENSE file should also be updated to add the
 necessary Netlib references.
 This is the standard place were people can look. Currently, the credits 
 are
 only in the BesselJ.java file,
 whic seems insufficient to me. As an example for Mersenne twister I put 
 the
 credits both in the
 java source for developers and in the NOTICE and LICENSE file for global
 references and end users.
 The NOTICE file is ONLY for REQUIRED attributions.
 It is vital that unnecessary content is excluded.

 Why, exactly?  It is a judgement call whether or not to attribute
 netlib here.  What exactly is the harm in adding the attribution in
 NOTICE.txt?  I see the policy-by-editing-the-website stuff in the
 link below, but personally see it as up to the RM to decide.  Saying
 in bold, don't add anything not legally required makes us all have
 to be lawyers, which we are not.  As a downstream user I like to
 know about the third party code used to create what we are
 distributing.

 AIUI the NOTICE file must be passed on to all downstream users, so it
 places an unnecessary burden on them.

 The NOTICE file is already necessary. The fact it has one line or one
 hundred does not change anything on the burden for end users.

Ah, but it may if a project includes several ASF components.
Each such NOTICE file will have to be examined to see if the contents
need to be passed on.

I did not make this rule up.

As far as I know, it was established by the ASF founders, such as Roy.


 Remember that the LICENSE file contains - or points to - all the
 licenses, so end users have all the license info they need.
 The NOTICE file is for required attributions only.

 OK, then I will revert the last change in NOTICE (preserving the
 attributions that were already there in the previous releases), and
 keep the new attribution only in the LICENSE file.


 I'm sure there are e-mails from Roy about and other ASF founders about
 this, but I think the link I quoted is very clear.

 If you want to challenge that page or ask for clarifications, please
 ask on the legal-discuss list.

 Maybe I'll do this, I'm not sure yet.

 As part of my day work, and despite I am not a lawyer, I have to help
 some projects be clear about their use of open-source components. Having
 a file that already includes everything without having to chase manually
 thousand of source files is a *relief*, not a burden.

 best regards,
 Luc



 http://www.apache.org/dev/licensing-howto.html#mod-notice

 The LICENSE file must contain ALL relevant licences - or pointers to
 local files containing the license.

 best regards,
 Luc

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

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





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


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

Re: [DISCUSS] Jira karma for ASF committers? (Was: Re: [ANNOUNCEMENT] Apache Commons grants write access to all ASF committers)

2014-12-18 Thread Jochen Wiedmann

 You're bringing up a valid point here... If ASF committers can change the
 code/fix bugs/implement new features, they should be able to modify the
 corresponding jira tickets.

They should be able... yes.
But does thatt mean we've got to enable it for all ASF now? I don't
think so. If someone's interested enough to work on JIRA stuff, he
would also be interested enough to ask for karma.

I think it's sufficient to let people know they can have, *if* they ask for it.

Jochen

On Thu, Dec 18, 2014 at 9:43 AM, Benedikt Ritter brit...@apache.org wrote:
 Hi Adrian,

 2014-12-18 3:47 GMT+01:00 Adrian Crum adrian.c...@sandglass-software.com:

 The challenge will be to keep Jira up-to-date. I would like to wrap up
 some Jira issues too, but ASF committers do not have edit permissions in
 Commons Jira.


 You're bringing up a valid point here... If ASF committers can change the
 code/fix bugs/implement new features, they should be able to modify the
 corresponding jira tickets.

 Benedikt



 Adrian Crum
 Sandglass Software
 www.sandglass-software.com


 On 12/18/2014 2:42 AM, Carl Hall wrote:

 Very cool!  I've been digging through the JIRA tickets for dbutils.  I
 would like to help clear those out and add some new things to the library.
 I'll be sure to send details to the list as things come up.

 On Mon, Dec 15, 2014 at 8:05 AM, Benedikt Ritter brit...@apache.org
 wrote:


 Dear fellow committers,

 The Apache Commons Team is pleased to announce that write access to the
 Apache Commons Subversion and Git repositories has been granted to all
 ASF
 committers.

 Apache Commons is an Apache project focused on all aspects of reusable
 Java
 components. As such, the components maintained by the Apache Commons
 project
 may be of interest to a variety of other Apache projects.

 The Apache Commons community would like to invite you to share and
 maintain
 useful code.

 While Apache Commons is a Commit-Then-Review community, we would consider
 it polite and helpful for contributors to announce their intentions and
 plans on the dev mailing list [1] before committing code.


 Have fun,

 Benedikt Ritter,
 on behalf of the Apache Commons Community

 [1] http://commons.apache.org/mail-lists.html

 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter



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



 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter



-- 
Our time is just a point along a line that runs forever with no end.
(Al Stewart, Lord Grenville)

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

Re: [DISCUSS] Jira karma for ASF committers? (Was: Re: [ANNOUNCEMENT] Apache Commons grants write access to all ASF committers)

On 18 December 2014 at 11:37, Jochen Wiedmann jochen.wiedm...@gmail.com wrote:
 You're bringing up a valid point here... If ASF committers can change the
 code/fix bugs/implement new features, they should be able to modify the
 corresponding jira tickets.

 They should be able... yes.
 But does thatt mean we've got to enable it for all ASF now? I don't
 think so. If someone's interested enough to work on JIRA stuff, he
 would also be interested enough to ask for karma.

 I think it's sufficient to let people know they can have, *if* they ask for 
 it.

+1

 Jochen

 On Thu, Dec 18, 2014 at 9:43 AM, Benedikt Ritter brit...@apache.org wrote:
 Hi Adrian,

 2014-12-18 3:47 GMT+01:00 Adrian Crum adrian.c...@sandglass-software.com:

 The challenge will be to keep Jira up-to-date. I would like to wrap up
 some Jira issues too, but ASF committers do not have edit permissions in
 Commons Jira.


 You're bringing up a valid point here... If ASF committers can change the
 code/fix bugs/implement new features, they should be able to modify the
 corresponding jira tickets.

 Benedikt



 Adrian Crum
 Sandglass Software
 www.sandglass-software.com


 On 12/18/2014 2:42 AM, Carl Hall wrote:

 Very cool!  I've been digging through the JIRA tickets for dbutils.  I
 would like to help clear those out and add some new things to the library.
 I'll be sure to send details to the list as things come up.

 On Mon, Dec 15, 2014 at 8:05 AM, Benedikt Ritter brit...@apache.org
 wrote:


 Dear fellow committers,

 The Apache Commons Team is pleased to announce that write access to the
 Apache Commons Subversion and Git repositories has been granted to all
 ASF
 committers.

 Apache Commons is an Apache project focused on all aspects of reusable
 Java
 components. As such, the components maintained by the Apache Commons
 project
 may be of interest to a variety of other Apache projects.

 The Apache Commons community would like to invite you to share and
 maintain
 useful code.

 While Apache Commons is a Commit-Then-Review community, we would consider
 it polite and helpful for contributors to announce their intentions and
 plans on the dev mailing list [1] before committing code.


 Have fun,

 Benedikt Ritter,
 on behalf of the Apache Commons Community

 [1] http://commons.apache.org/mail-lists.html

 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter



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



 --
 http://people.apache.org/~britter/
 http://www.systemoutprintln.de/
 http://twitter.com/BenediktRitter
 http://github.com/britter



 --
 Our time is just a point along a line that runs forever with no end.
 (Al Stewart, Lord Grenville)

 -
 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

Commons RDF

Hi all,

Following the recent announcement and as mentioned yesterday I've started
some steps towards commons RDF.

The Apache Clerezza project has the goal to provide an API modeling the
W3C RDF standard without any vendor specific additions. We have been
providing such an API for several years now and it has been used in several
EU research project and by the Dutch government.

As Clerezza provides much more than just the API and many are just
interested in this API without being interested in the rest of Clerezza it
would be good to have this API as apache commons. The API could also need
some brush up following the experience of the past years as well as
alignment with other API proposal.

I'm not sure about hwat the steps should be done for the purpose of
creating commons RDF.

What I've done so far;
- Discussion on Clerezza Mailing list [1]
- Opened issue COMMONSSITE-80
- Committed some initial code to the sandbox [2]

I would be thankful for advice on how to proceed.

Cheers,
Reto


1.
http://mail-archives.apache.org/mod_mbox/clerezza-dev/201412.mbox/%3CCALvhUEVDfTSWZV%2B2FPMiup%2Bs1BPJUZjL5mW_4%3D5%2BRPN14SZzAg%40mail.gmail.com%3E
2. http://svn.apache.org/repos/asf/commons/sandbox/rdf/trunk/

Re: Commons RDF

Hello Reto,

2014-12-18 13:29 GMT+01:00 Reto Gmür r...@apache.org:

Hi all,

Following the recent announcement and as mentioned yesterday I've started
some steps towards commons RDF.

The Apache Clerezza project has the goal to provide an API modeling the
W3C RDF standard without any vendor specific additions. We have been
providing such an API for several years now and it has been used in several
EU research project and by the Dutch government.

As Clerezza provides much more than just the API and many are just
interested in this API without being interested in the rest of Clerezza it
would be good to have this API as apache commons. The API could also need
some brush up following the experience of the past years as well as
alignment with other API proposal.

I'm not sure about hwat the steps should be done for the purpose of
creating commons RDF.

What I've done so far;
- Discussion on Clerezza Mailing list [1]
- Opened issue COMMONSSITE-80
- Committed some initial code to the sandbox [2]

I would be thankful for advice on how to proceed.

*copy pasting my answer from the other thread*

Regrads,
Benedikt

[1] http://markmail.org/message/dtvy7mpm7gd7kvdw
[2] http://git.apache.org/

Cheers,
Reto

http://mail-archives.apache.org/mod_mbox/clerezza-dev/201412.mbox/%3CCALvhUEVDfTSWZV%2B2FPMiup%2Bs1BPJUZjL5mW_4%3D5%2BRPN14SZzAg%40mail.gmail.com%3E
2. http://svn.apache.org/repos/asf/commons/sandbox/rdf/trunk/

--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [DISCUSS] Jira karma for ASF committers? (Was: Re: [ANNOUNCEMENT] Apache Commons grants write access to all ASF committers)

On Thu, Dec 18, 2014 at 6:49 AM, sebb seb...@gmail.com wrote:

 On 18 December 2014 at 11:37, Jochen Wiedmann jochen.wiedm...@gmail.com
 wrote:
  You're bringing up a valid point here... If ASF committers can change
 the
  code/fix bugs/implement new features, they should be able to modify the
  corresponding jira tickets.
 
  They should be able... yes.
  But does thatt mean we've got to enable it for all ASF now? I don't
  think so. If someone's interested enough to work on JIRA stuff, he
  would also be interested enough to ask for karma.
 
  I think it's sufficient to let people know they can have, *if* they ask
 for it.

 +1


+1 for now. It seems reasonable. We've just removed a big obstacle to
Commons development within Apache. Let's see if JIRA is another now that
we've opened the gates.

Gary



  Jochen
 
  On Thu, Dec 18, 2014 at 9:43 AM, Benedikt Ritter brit...@apache.org
 wrote:
  Hi Adrian,
 
  2014-12-18 3:47 GMT+01:00 Adrian Crum 
 adrian.c...@sandglass-software.com:
 
  The challenge will be to keep Jira up-to-date. I would like to wrap up
  some Jira issues too, but ASF committers do not have edit permissions
 in
  Commons Jira.
 
 
  You're bringing up a valid point here... If ASF committers can change
 the
  code/fix bugs/implement new features, they should be able to modify the
  corresponding jira tickets.
 
  Benedikt
 
 
 
  Adrian Crum
  Sandglass Software
  www.sandglass-software.com
 
 
  On 12/18/2014 2:42 AM, Carl Hall wrote:
 
  Very cool!  I've been digging through the JIRA tickets for dbutils.  I
  would like to help clear those out and add some new things to the
 library.
  I'll be sure to send details to the list as things come up.
 
  On Mon, Dec 15, 2014 at 8:05 AM, Benedikt Ritter brit...@apache.org
  wrote:
 
 
  Dear fellow committers,
 
  The Apache Commons Team is pleased to announce that write access to
 the
  Apache Commons Subversion and Git repositories has been granted to
 all
  ASF
  committers.
 
  Apache Commons is an Apache project focused on all aspects of
 reusable
  Java
  components. As such, the components maintained by the Apache Commons
  project
  may be of interest to a variety of other Apache projects.
 
  The Apache Commons community would like to invite you to share and
  maintain
  useful code.
 
  While Apache Commons is a Commit-Then-Review community, we would
 consider
  it polite and helpful for contributors to announce their intentions
 and
  plans on the dev mailing list [1] before committing code.
 
 
  Have fun,
 
  Benedikt Ritter,
  on behalf of the Apache Commons Community
 
  [1] http://commons.apache.org/mail-lists.html
 
  --
  http://people.apache.org/~britter/
  http://www.systemoutprintln.de/
  http://twitter.com/BenediktRitter
  http://github.com/britter
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
  For additional commands, e-mail: dev-h...@commons.apache.org
 
 
 
  --
  http://people.apache.org/~britter/
  http://www.systemoutprintln.de/
  http://twitter.com/BenediktRitter
  http://github.com/britter
 
 
 
  --
  Our time is just a point along a line that runs forever with no end.
  (Al Stewart, Lord Grenville)
 
  -
  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



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [DISCUSS] Jira karma for ASF committers? (Was: Re: [ANNOUNCEMENT] Apache Commons grants write access to all ASF committers)

2014-12-18 Thread Mark Thomas

On 18/12/2014 11:37, Jochen Wiedmann wrote:
 You're bringing up a valid point here... If ASF committers can change the
 code/fix bugs/implement new features, they should be able to modify the
 corresponding jira tickets.
 
 They should be able... yes.
 But does thatt mean we've got to enable it for all ASF now?

Why not?

I think we have far too many unnecessary, technical controls in Jira. If
social controls are good enough for svn why aren't they good enough for
Jira?

Mark


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

Re: [DISCUSS] Jira karma for ASF committers? (Was: Re: [ANNOUNCEMENT] Apache Commons grants write access to all ASF committers)

2014-12-18 Thread Duncan Jones

On 18 December 2014 at 13:03, Mark Thomas ma...@apache.org wrote:
 On 18/12/2014 11:37, Jochen Wiedmann wrote:
 You're bringing up a valid point here... If ASF committers can change the
 code/fix bugs/implement new features, they should be able to modify the
 corresponding jira tickets.

 They should be able... yes.
 But does thatt mean we've got to enable it for all ASF now?

 Why not?

 I think we have far too many unnecessary, technical controls in Jira. If
 social controls are good enough for svn why aren't they good enough for
 Jira?

 Mark

I agree with Mark. The goal of opening up SVN access was to lower the
barrier to entry for other ASF developers. But a conscientious
developer would want to perform activity in Jira, so there is still a
barrier.

If we're talking about risks, access to SVN trumps Jira access any day, IMO.

Duncan



 -
 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: Commons RDF

Hi Benedikt,

On Thu, Dec 18, 2014 at 12:43 PM, Benedikt Ritter brit...@apache.org
wrote:

Hello Reto,

2014-12-18 13:29 GMT+01:00 Reto Gmür r...@apache.org:

Hi all,

Following the recent announcement and as mentioned yesterday I've started
some steps towards commons RDF.

The Apache Clerezza project has the goal to provide an API modeling the
W3C RDF standard without any vendor specific additions. We have been
providing such an API for several years now and it has been used in
several
EU research project and by the Dutch government.

As Clerezza provides much more than just the API and many are just
interested in this API without being interested in the rest of Clerezza
it
would be good to have this API as apache commons. The API could also need
some brush up following the experience of the past years as well as
alignment with other API proposal.

I'm not sure about hwat the steps should be done for the purpose of
creating commons RDF.

What I've done so far;
- Discussion on Clerezza Mailing list [1]
- Opened issue COMMONSSITE-80
- Committed some initial code to the sandbox [2]

I would be thankful for advice on how to proceed.

*copy pasting my answer from the other thread*

That's great, your help is very welcome. Good to know there's already a
git project, I'll move the code over. Another issue is the creation of a
JIRA project.

Cheers,
Reto

Regrads,
Benedikt

[1] http://markmail.org/message/dtvy7mpm7gd7kvdw
[2] http://git.apache.org/

Cheers,
Reto

--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: Commons RDF

2014-12-18 14:10 GMT+01:00 Reto Gmür r...@apache.org:

Hi Benedikt,

On Thu, Dec 18, 2014 at 12:43 PM, Benedikt Ritter brit...@apache.org
wrote:

Hello Reto,

2014-12-18 13:29 GMT+01:00 Reto Gmür r...@apache.org:

Hi all,

Following the recent announcement and as mentioned yesterday I've
started
some steps towards commons RDF.

The Apache Clerezza project has the goal to provide an API modeling
the
W3C RDF standard without any vendor specific additions. We have been
providing such an API for several years now and it has been used in
several
EU research project and by the Dutch government.

As Clerezza provides much more than just the API and many are just
interested in this API without being interested in the rest of Clerezza
it
would be good to have this API as apache commons. The API could also
need
some brush up following the experience of the past years as well as
alignment with other API proposal.

I'm not sure about hwat the steps should be done for the purpose of
creating commons RDF.

What I've done so far;
- Discussion on Clerezza Mailing list [1]
- Opened issue COMMONSSITE-80
- Committed some initial code to the sandbox [2]

I would be thankful for advice on how to proceed.

*copy pasting my answer from the other thread*

We had a similar proposal a while ago [1]. Is the Clerezza RDF library
related to this proposal? In the end the people around
https://github.com/commons-rdf/commons-rdf decided not to bring their
code
to Apache Commons, because they wanted to use github for development and
discussions. They already requested the commons-rdf git repository from
infra, which is now unused [2]. So if you want to bring your RDF library
to
commons, we can use that repo, I guess... I can help you with
bootstraping
the component and bring up a website.

That's great, your help is very welcome. Good to know there's already a
git project, I'll move the code over. Another issue is the creation of a
JIRA project.

Hello Reto,

usually projects at commons start in the sandbox. We don't create JIRA
projects for sandbox components, but instead use the SANDBOX project in
jira [1]. I've created a new component for the project called RDF which
you can use for RDF. When a commons component is promoted to proper we
create an individual Jira project (this usually happens when we release
version 1.0).

Benedikt

[1] https://issues.apache.org/jira/browse/SANDBOX

Cheers,
Reto

Regrads,
Benedikt

[1] http://markmail.org/message/dtvy7mpm7gd7kvdw
[2] http://git.apache.org/

Cheers,
Reto

--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [TEXT] Distance vs. Metric vs. Similarity

2014-12-14 23:10 GMT+01:00 Bruno P. Kinoshita brunodepau...@yahoo.com.br:

  Sounds good, although I'm not sure I understand where you are going
 with the marker interface. What is it's purpose?
 Let's then keep the StringMetric interface and update its Javadoc.
 Thinking again, that other marker interface seems to be unnecessary.  
 Okay, but we need to make sure all algorithms really return a
 distance then. As I said, FuzzyDistance currently really returns a
 similarity score. An algorithm returning a distance should return a higher
 number for higher distances. I had a look at the code, and I think I
 understand what you are saying now. In FuzzyDistance, the higher the score,
 the closer strings are. Different than what the other algorithms return.
 I believe I found why I named that package similarity. Probably it was
 because I saw that in the stringmetric library [1]. There, Levenshtein,
 Jaccard and other algorithms are suffixed with Metric.
 How about we keep the package as similarity and simply rename the classes
 to [Algo]Metric too? This way we will be able to accommodate other metrics
 such as the Sorensen-Dice coefficient, where the higher the coefficient,
 more similar two strings are.
 WDYT?



Hey Bruno,

yes we can do it that way. What I want to avoid is, that the users have to
check the JavaDoc every time they use an algorithms. To me it would make
sense to have a number of distance algorithms and they all return a
distance. Or we have Similarity algorithms and they all return a
similarity. That way users can swap out the underlying algorithms without
changing their code.

Benedikt


 CheersBruno
 [1] https://github.com/rockymadden/stringmetric



   From: Benedikt Ritter brit...@apache.org
  To: Commons Developers List dev@commons.apache.org; Bruno P. Kinoshita
 brunodepau...@yahoo.com.br
  Sent: Sunday, December 14, 2014 6:45 PM
  Subject: Re: [TEXT] Distance vs. Metric vs. Similarity

 Hi Bruna,



 2014-12-14 21:37 GMT+01:00 Bruno P. Kinoshita brunodepau...@yahoo.com.br
 :
 
  Hello Benedikt!
   Metric feels like it's something more general, but I'm not sure.
  You're right. Metric was supposed to be a general interface,
  representing the String Metric from the Wikipedia article.
and the interface from StringMetric to StringDistance.
  I'm reading the Myers paper, and already have a local branch with the
  Myers algorithm from [collections] ported to [text].
  Perhaps we could move the StringMetric interface to o.a.c.text package,
  and create StringDistance or EditDistance interface in
 o.a.c.text.distance.
  This way we can have String Metrics as in Wikipedia, as being a way of
  giving a valuefor comparing two strings. We would have the edit distances
  in the distance package, and the diff algorithms in another diff package.
  All of them being String Metrics.
  What do you think?
 

 Sounds good, although I'm not sure I understand where you are going with
 the marker interface. What is it's purpose?


I think we should consider renaming everything to distance, since
  the  implemented algorithms all end on *Distance. So we would change
 the
  package  name from o.a.c.text.similarity to o.a.c.text.distance and the
  interface  from StringMetric to StringDistance. 
   Looking at the code again, it seems like the algorithms all really
  return a similarity score and not a distance. For exmaple FuzzyDistance
  JavaDoc states: A higher score indicates a higher similarity. If this
 is
  a case, maybe it makes more sense to rename everything to Similarity?
  I'm in favor of dropping score and similarity, and adopting distance in
  the package, classes and javadocs, as it is used in other tools (e.g.
 Solr,
  Talend, Informatica IIR, etc).
 

 Okay, but we need to make sure all algorithms really return a distance
 then. As I said, FuzzyDistance currently really returns a similarity score.
 An algorithm returning a distance should return a higher number for higher
 distances.

 Benedikt


  All the best,Bruno
 
 
   From: Benedikt Ritter brit...@apache.org
   To: Commons Developers List dev@commons.apache.org
   Sent: Sunday, December 14, 2014 6:20 PM
   Subject: Re: [TEXT] Distance vs. Metric vs. Similarity
 
  2014-12-14 21:08 GMT+01:00 Benedikt Ritter brit...@apache.org:
  
   Hi,
  
   currently the wording in commons text is a bit confusing. We have the
   three terms:
  
   - distance
   - similarity
   - metric
  
   Distance and similarity seem to be just opposites of the same thing. A
   great distance indicates a small similarity between two character
   sequences. Metric feels like it's something more general, but I'm not
  sure.
  
   I think we should consider renaming everything to distance, since the
   implemented algorithms all end on *Distance. So we would change the
  package
   name from o.a.c.text.similarity to o.a.c.text.distance and the
 interface
   from StringMetric to StringDistance.
  
 
  Looking at the code again, it seems like the

Re: [VOTE] Release Configuration 2.0-alpha2 based on RC1

Looks good for an alpha2: +1

Tested on:

Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
2014-08-11T16:58:10-04:00)
Maven home: C:\Java\apache-maven-3.2.3
Java version: 1.7.0_71, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_71\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows

With Java 8, Javadoc doclint errors abound. My set up:

Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4;
2014-08-11T16:58:10-04:00)
Maven home: C:\Java\apache-maven-3.2.3
Java version: 1.8.0_25, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_25\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: dos

Gary

On Fri, Dec 12, 2014 at 3:38 PM, Oliver Heger oliver.he...@oliver-heger.de
wrote:

Hi all,

this is a vote for the second alpha version of [configuration] 2.0 based
on the first release candidate. After the first alpha version, a couple
of enhancement requests have been implemented causing some minor changes
on interfaces. Details are available in the release notes.

The same disclaimer applies as for the first alpha release:
- This release is according to the release often and early mantra. It
is not yet perfect (e.g. there are lots of checkstyle errors, and it is
expected that there are still some API changes). The purpose is to get
feedback from the community regarding the new concepts implemented in
this version. I hope, I have made this clear in the release notes.
- In the past we decided that alpha releases should not go to Maven
central. Therefore, I did not deploy the artifacts to Nexus; only the
distributions were created.

Configuration 2.0-alpha2 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/configuration
(revision 7395)

Details of changes since 1.10 and the first alpha version are in the
release notes:

https://dist.apache.org/repos/dist/dev/commons/configuration/RELEASE-NOTES.txt

http://people.apache.org/~oheger/configuration-2.0-alpha2-rc1/changes-report.html

Here is the tag:

http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_0_alpha2_RC1
(revision 1644517)

Site:
http://people.apache.org/~oheger/configuration-2.0-alpha2-rc1/
(note some links in the menu for version 1.10 are not yet working)

KEYS:
http://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now, i.e. after 2000
GMT 15-December 2014

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thanks!
Oliver

-
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
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE] Release Configuration 2.0-alpha2 based on RC1

Hello Oliver,

I've tested with Maven 3.2.3 and Java 7 and 8.

- The build works finde with both Java versions. I get a lot of log
statements when executing tests. IMHO tests should not write log messages.
- Signs and hashes are good
- Artifact contents look good
- Clirr shows some errors, but since we are not publishing to maven
central, I don't see this as a problem
- Site can not be build with Java 8 - this should be fixed before we go GA.

Benedikt

2014-12-12 21:38 GMT+01:00 Oliver Heger oliver.he...@oliver-heger.de:

Hi all,

Configuration 2.0-alpha2 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/configuration
(revision 7395)

Details of changes since 1.10 and the first alpha version are in the
release notes:

https://dist.apache.org/repos/dist/dev/commons/configuration/RELEASE-NOTES.txt

http://people.apache.org/~oheger/configuration-2.0-alpha2-rc1/changes-report.html

Here is the tag:

http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_0_alpha2_RC1
(revision 1644517)

Site:
http://people.apache.org/~oheger/configuration-2.0-alpha2-rc1/
(note some links in the menu for version 1.10 are not yet working)

KEYS:
http://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now, i.e. after 2000
GMT 15-December 2014

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thanks!
Oliver

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

--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [VOTE] Release Configuration 2.0-alpha2 based on RC1

On Thu, Dec 18, 2014 at 9:44 AM, Benedikt Ritter brit...@apache.org wrote:

Hello Oliver,

I've tested with Maven 3.2.3 and Java 7 and 8.

But the jars _will_ be published to MC.
The Clirr errors do not matter because we are breaking BC in version 2 AND
it is OK to break BC between alphas since we are breaking it with version 1.

Gary

- Site can not be build with Java 8 - this should be fixed before we go GA.

Benedikt

2014-12-12 21:38 GMT+01:00 Oliver Heger oliver.he...@oliver-heger.de:

Hi all,

Configuration 2.0-alpha2 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/configuration
(revision 7395)

Details of changes since 1.10 and the first alpha version are in the
release notes:

https://dist.apache.org/repos/dist/dev/commons/configuration/RELEASE-NOTES.txt

http://people.apache.org/~oheger/configuration-2.0-alpha2-rc1/changes-report.html

Here is the tag:

http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_0_alpha2_RC1
(revision 1644517)

Site:
http://people.apache.org/~oheger/configuration-2.0-alpha2-rc1/
(note some links in the menu for version 1.10 are not yet working)

KEYS:
http://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now, i.e. after 2000
GMT 15-December 2014

[ ] +1 Release these artifacts
[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thanks!
Oliver

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

--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: Commons RDF

On Thu, Dec 18, 2014 at 1:24 PM, Benedikt Ritter brit...@apache.org wrote:

2014-12-18 14:10 GMT+01:00 Reto Gmür r...@apache.org:

Hi Benedikt,

On Thu, Dec 18, 2014 at 12:43 PM, Benedikt Ritter brit...@apache.org
wrote:

Hello Reto,

2014-12-18 13:29 GMT+01:00 Reto Gmür r...@apache.org:

Hi all,

Following the recent announcement and as mentioned yesterday I've
started
some steps towards commons RDF.

The Apache Clerezza project has the goal to provide an API modeling
the
W3C RDF standard without any vendor specific additions. We have been
providing such an API for several years now and it has been used in
several
EU research project and by the Dutch government.

As Clerezza provides much more than just the API and many are just
interested in this API without being interested in the rest of
Clerezza
it
would be good to have this API as apache commons. The API could also
need
some brush up following the experience of the past years as well as
alignment with other API proposal.

I'm not sure about hwat the steps should be done for the purpose of
creating commons RDF.

What I've done so far;
- Discussion on Clerezza Mailing list [1]
- Opened issue COMMONSSITE-80
- Committed some initial code to the sandbox [2]

I would be thankful for advice on how to proceed.

*copy pasting my answer from the other thread*

We had a similar proposal a while ago [1]. Is the Clerezza RDF library
related to this proposal? In the end the people around
https://github.com/commons-rdf/commons-rdf decided not to bring their
code
to Apache Commons, because they wanted to use github for development
and
discussions. They already requested the commons-rdf git repository from
infra, which is now unused [2]. So if you want to bring your RDF
library
to
commons, we can use that repo, I guess... I can help you with
bootstraping
the component and bring up a website.

That's great, your help is very welcome. Good to know there's already a
git project, I'll move the code over. Another issue is the creation of a
JIRA project.

Hello Reto,

Benedikt

Hi Benedikt,

Thanks, I'll create issues there.

I just wanted to push to git and it complains that my password is invalid.
...but the same password worked with svn and on clerezza. has this repo
been opened already?

Cheers,
Reto

[1] https://issues.apache.org/jira/browse/SANDBOX

Cheers,
Reto

Regrads,
Benedikt

[1] http://markmail.org/message/dtvy7mpm7gd7kvdw
[2] http://git.apache.org/

Cheers,
Reto

--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [DISCUSS] Jira karma for ASF committers? (Was: Re: [ANNOUNCEMENT] Apache Commons grants write access to all ASF committers)

2014-12-18 Thread Phil Steitz

On 12/18/14 6:03 AM, Mark Thomas wrote:
 On 18/12/2014 11:37, Jochen Wiedmann wrote:
 You're bringing up a valid point here... If ASF committers can change the
 code/fix bugs/implement new features, they should be able to modify the
 corresponding jira tickets.
 They should be able... yes.
 But does thatt mean we've got to enable it for all ASF now?
 Why not?

 I think we have far too many unnecessary, technical controls in Jira. If
 social controls are good enough for svn why aren't they good enough for
 Jira?

+1 - is it easy to identify ASF committers in the JIRA user base and
somehow batch this?

Phil

 Mark


 -
 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: [VOTE] Release Configuration 2.0-alpha2 based on RC1

2014-12-18 Thread Thomas Neidhart

On 12/12/2014 09:38 PM, Oliver Heger wrote:
Hi all,

Configuration 2.0-alpha2 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/configuration
(revision 7395)

Details of changes since 1.10 and the first alpha version are in the
release notes:

https://dist.apache.org/repos/dist/dev/commons/configuration/RELEASE-NOTES.txt

http://people.apache.org/~oheger/configuration-2.0-alpha2-rc1/changes-report.html

Here is the tag:

http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_0_alpha2_RC1
(revision 1644517)

Site:
http://people.apache.org/~oheger/configuration-2.0-alpha2-rc1/
(note some links in the menu for version 1.10 are not yet working)

KEYS:
http://www.apache.org/dist/commons/KEYS

Please review the release candidate and vote.
This vote will close no sooner than 72 hours from now, i.e. after 2000
GMT 15-December 2014

[x] +1 Release these artifacts

Thomas

[ ] +0 OK, but...
[ ] -0 OK, but really should fix...
[ ] -1 I oppose this release because...

Thanks!
Oliver

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

Re: Commons RDF

On Thu, Dec 18, 2014 at 3:17 PM, Reto Gmür r...@wymiwyg.com wrote:

On Thu, Dec 18, 2014 at 1:24 PM, Benedikt Ritter brit...@apache.org
wrote:

2014-12-18 14:10 GMT+01:00 Reto Gmür r...@apache.org:

Hi Benedikt,

On Thu, Dec 18, 2014 at 12:43 PM, Benedikt Ritter brit...@apache.org
wrote:

Hello Reto,

2014-12-18 13:29 GMT+01:00 Reto Gmür r...@apache.org:

Hi all,

Following the recent announcement and as mentioned yesterday I've
started
some steps towards commons RDF.

The Apache Clerezza project has the goal to provide an API modeling
the
W3C RDF standard without any vendor specific additions. We have
been
providing such an API for several years now and it has been used in
several
EU research project and by the Dutch government.

As Clerezza provides much more than just the API and many are just
interested in this API without being interested in the rest of
Clerezza
it
would be good to have this API as apache commons. The API could also
need
some brush up following the experience of the past years as well as
alignment with other API proposal.

I'm not sure about hwat the steps should be done for the purpose of
creating commons RDF.

What I've done so far;
- Discussion on Clerezza Mailing list [1]
- Opened issue COMMONSSITE-80
- Committed some initial code to the sandbox [2]

I would be thankful for advice on how to proceed.

*copy pasting my answer from the other thread*

We had a similar proposal a while ago [1]. Is the Clerezza RDF library
related to this proposal? In the end the people around
https://github.com/commons-rdf/commons-rdf decided not to bring their
code
to Apache Commons, because they wanted to use github for development
and
discussions. They already requested the commons-rdf git repository
from
infra, which is now unused [2]. So if you want to bring your RDF
library
to
commons, we can use that repo, I guess... I can help you with
bootstraping
the component and bring up a website.

That's great, your help is very welcome. Good to know there's already
a
git project, I'll move the code over. Another issue is the creation of a
JIRA project.

Hello Reto,

Benedikt

Hi Benedikt,

Thanks, I'll create issues there.

I just wanted to push to git and it complains that my password is invalid.
...but the same password worked with svn and on clerezza. has this repo
been opened already?

After resetting password it no longer complains about that, but gives a
clearer message:

Password for 'https://r...@git-wip-us.apache.org':
...
remote: You are not authorized to edit this repository.
remote:
To https://r...@git-wip-us.apache.org/repos/asf/commons-rdf.git
! [remote rejected] master - master (pre-receive hook declined)
error: failed to push some refs to '
https://r...@git-wip-us.apache.org/repos/asf/commons-rdf.git

Cheers,
Reto

[1] https://issues.apache.org/jira/browse/SANDBOX

Cheers,
Reto

Regrads,
Benedikt

[1] http://markmail.org/message/dtvy7mpm7gd7kvdw
[2] http://git.apache.org/

Cheers,
Reto

--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [compress] Changes to allow multithreaded creation of zip files

2014-12-18 Thread Kristian Rosenvold

I just landed two commits for COMMONS-295 and COMMONS-296, which is
the groundwork for proper parallel support. The icing on the cake (the
high-level api with nThreads configuration and single point of
entry) is still work-in-progress and can be seen at
https://github.com/krosenvold/commons-compress/tree/concurrentSupport

It's still early days for the high level service; it needs to do
lots of funky stuff like balance large files first and use work
stealing towards the end. Currently I can easily make this use 850%
CPU on my 6 core cpu.

The cool stuff is still in github, but it's a lot easier for
anyone to build and play around with now.

Kristian


2014-12-18 9:29 GMT+01:00 Kristian Rosenvold krosenv...@apache.org:
 +1 for moving to git btw :)

 Kristian

 2014-12-15 11:38 GMT+01:00 Emmanuel Bourg ebo...@apache.org:
 Le 15/12/2014 11:36, Stefan Bodewig a écrit :

 [as an aside, maybe we should think about moving Compress to git]

 +1

 Emmanuel


 -
 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: Git Push Summary

2014-12-18 Thread Emmanuel Bourg

Le 18/12/2014 21:31, l...@apache.org a écrit :
 Repository: commons-math
 Updated Tags:  refs/tags/MATH_3_4_RC1 [created] f38f96a0b

Tag notifications are missing the component prefix. I opened a ticket to
address this (INFRA-8916).

Emmanuel Bourg


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

Re: Commons RDF

2014-12-18 Thread Andy Seaborne

I am rather surprised by the approach here.

There are several RDF-related projects - Jena, Marmotta, Any23, Stanbol,
Clerezza and other that use RDF.

How do they fit in?

reto wrote:

Following the recent announcement and as mentioned yesterday I've started
some steps towards commons RDF.

How do those projects fit in?

On the Clerezza list there has been support for working with
/commons-rdf/commons-rdf [1] No other project has been contacted.

There is a community, with a significant number of participants and
significant discussion, sometimes quite intense, at

https://github.com/commons-rdf/commons-rdf/issues

from both ASF committers and people outside ASF. The work was
communicated to all Apache RDF-related projects from the start.

The hope, at least my hope, has always been to bring this to Apache IF
it got some traction with users. This is stated in [2]

There is SANDBOX-479 still open. This is a blocker to bringing code in.

Benedikt wrote:

*copy pasting my answer from the other thread*

Clerezza is unrelated to commons-rdf. Do not be fooled by the many uses
of the word commons :-)

There are several RDF systems for the JVM - not all of them here at ASF.
To build community around the controversial area of RDF APIs (they
have always been controversial since day one in RDF land - much history).

Starting from one existing project's API is a non-starter, if nothing
else, from a social perspective. Two major RDF systems go back 13 years.

Having initial discussion on apache-commons lists was felt not to be
ideal to create community across groups not at Apache.

As I recall, it was the details of the commons processes that was felt
to be unhelpful *initially*. Too many other things going on in the same
list for one. To engage as widely as possible, we started on github -
neutral ground.

Benedikt wrote:
I've created a new component for the project called RDF which
you can use for RDF. When a commons component is promoted to proper we
create an individual Jira project (this usually happens when we
release version 1.0).

Now we have a new endeavour here without them. It is very unfair to
call this commons or grab RDF.

Now I see:

rdf/trunk/src/main/java/org/apache/commons/rdf/Graph.java

r1646333 | ...

COMMONSSITE-80: renamed some classes to reflect new terms and standards
of RDf 1.1, Took some names and terms from
https://github.com/commons-rdf/commons-rdf

Please first reach out to all parties and not just copy one codebase over.

I apologise for not knowing more about the ethos of Apache Commons.

Andy

[1]
http://mail-archives.apache.org/mod_mbox/clerezza-dev/201412.mbox/%3C5491AB06.9030601%40apache.org%3E

and thread

[2]
https://github.com/commons-rdf/commons-rdf/blob/master/CONTRIBUTING.md

[3]
https://github.com/commons-rdf/commons-rdf/issues

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

Re: [Math] Would like to know, if extensions are needed

2014-12-18 Thread Thorsten Kiefer


Hello,

Am 03.12.2014 um 12:53 schrieb Gilles:

Hello.

On Wed, 03 Dec 2014 10:13:08 +0100, Thorsten Kiefer wrote:

Hi,
the port is now finished.
The code may still contain bugs.
Maybe alpha-state.
But if you like it, you can add it.


Thank you for offering code to enhance the scope of Commons Math.
Yet I must emphasize that one of the goals of the project is to
provide an integrated set of functionalities (a.o. consistent
style and API throughout the codebase, full documentation and test
coverage).
Another on-going task is to include contributors who will stay and
maintain the codebase.
We do not usually have the resources neither to integrate a new
functionality, nor to maintain it afterwards.

You are very welcome to explain the purpose and state of your
contribution; then we can start a discussion on how to move toward
including the code in Commons Math.


The purpose of my project is a learning algorithm, which uses
function approximation and reinforcement learning.
With reinforcement learning a so-called agent can learn
optimal behaviour from only receiving rewards
for actions done in perceived states.

At the moment I am having problems to stabilize the algorithms.
The topology of the approximation functions and the initial
values for the parameters are essential for success.

At the moment only the fourier basis is practical as
approximation function.


Naively one would create a lookup table of scores for state-action pairs.
As the impractical huge size of these lookup tables is the problem,
the lookup table is being interpolated by an approximation function.

The lookup table and respectively the approximation function
map state-action pairs to scorings.

The RL algorithm adujsts the scorings during simulation.
And then it can decide, which action to take, by aiming for the highest 
score.


But still all unstable.



Regards
Thorsten Kiefer




Thanks for your interest in the project,
Gilles




Best Regards
Thorsten Kiefer


Am 17.11.2014 um 23:57 schrieb Thorsten Kiefer:

Hi,
I decided to port it to java, and if you should like it, you can extend
[Math] with RL algorithms.

https://github.com/toki78/JuRLs/tree/master/JuRLs/src/jurls/core
It will take a while, until I ported it all to java.

Regards
Thorsten


Am 15.11.2014 um 15:01 schrieb Gilles:

On Sat, 15 Nov 2014 14:32:07 +0100, Thorsten Kiefer wrote:

Hello,

Am 15.11.2014 um 13:39 schrieb Gilles:

Hello.

On Sat, 15 Nov 2014 06:15:32 +0100, Thorsten Kiefer wrote:

Hi,
I coded this in JavaScript :
http://toki78.github.io/

I am wondering, if parts of this might be useful for the math 
module.

If so, I could contribute it.


There are some machine-learning algorithms in Commons Math, more
would probably be welcome.
Could you perhaps describe with a little more details what you are
proposing?

I would like to implement a (non-turing-complete) meta languge


I don't think that CM would be the right place for a special-purpose
language. [Some time ago, there was a proposal for a language to
create arithmetical expressions.]
If you think otherwise, could you provide some rationale, so that we
can comment on concrete arguments?


for
the approximation function and the RL-update rule.
Then I would provide Q(lambda) and SARSA(lambda) using the fourier 
basis.

Might be useful for somebody.


Perhaps. I don't know what are RL, Q, SARSA.


The Meta-compiler's result could implement the interfaces used by the
FunctionFitters.
As far as I can remember : MultivariateFunction or so...


This looks like your project would depend on Commons Math, but need 
not

be part of it.

For more understanding you can also look up the code on my git 
profile.


I tried to read README.md: it just says My website...
Care to give a link to a description?  Thanks.


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

[VOTE][RC1] Release Commons Math 3.4

2014-12-18 Thread Luc Maisonobe

This is a [VOTE] for releasing Apache Commons Math 3.4.

Note that since [math] now uses git, access to the tag is slightly
different from other components. To clone a fresh tag, run this command
(beware I have split it in 2 lines below):

  git clone https://git-wip-us.apache.org/repos/asf/commons-math.git \
--branch MATH_3_4_RC1

To verify the tag (as git does sign tags with GPG), use this:

  cd commons-math
  git tag -v MATH_3_4_RC1

The site will be available in the staging area, it takes a few hours to
transfer from my machine:
  http://commons.staging.apache.org/proper/commons-math/

Distribution files:
  https://dist.apache.org/repos/dist/dev/commons/math/

Maven artifacts:

https://repository.apache.org/content/repositories/orgapachecommons-1066/org/apache/commons/commons-math3/3.4/


[ ] +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 close in 72 hours, at 2014-12-21T23:15:00Z (this is UTC
time).

best regards,
Luc

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

Re: [VOTE][RC1] Release Commons Math 3.4

On 18 December 2014 at 23:19, Luc Maisonobe l...@spaceroots.org wrote:
 This is a [VOTE] for releasing Apache Commons Math 3.4.

 Note that since [math] now uses git, access to the tag is slightly
 different from other components. To clone a fresh tag, run this command
 (beware I have split it in 2 lines below):

   git clone https://git-wip-us.apache.org/repos/asf/commons-math.git \
 --branch MATH_3_4_RC1

-1

This is insufficient to identify the code; branches are not immutable.

Most (all?) other Git projects use a URL which includes the hash.
For example, a current Incubator vote includes the following:

The Git commit ID is 94b42b85e80efd817f951326238864
e37edc2cb0
https://git-wip-us.apache.org/repos/asf?p=incubator-brooklyn.git;a=commit;h=94b42b85e80efd817f951326238864e37edc2cb0



 To verify the tag (as git does sign tags with GPG), use this:

   cd commons-math
   git tag -v MATH_3_4_RC1

 The site will be available in the staging area, it takes a few hours to
 transfer from my machine:
   http://commons.staging.apache.org/proper/commons-math/

 Distribution files:
   https://dist.apache.org/repos/dist/dev/commons/math/

-1

The revision number is needed in order to uniquely identify the
artifacts being voted on.
Alternatively, provide hashes.

 Maven artifacts:

 https://repository.apache.org/content/repositories/orgapachecommons-1066/org/apache/commons/commons-math3/3.4/


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

-1

The NOTICE file needs severe pruning.
I don't think any of the attributions are required.

 This vote will close in 72 hours, at 2014-12-21T23:15:00Z (this is UTC
 time).

 best regards,
 Luc

 -
 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: [VOTE][RC1] Release Commons Math 3.4

2014-12-18 Thread Luc Maisonobe

Le 19/12/2014 00:50, sebb a écrit :
 On 18 December 2014 at 23:19, Luc Maisonobe l...@spaceroots.org wrote:
 This is a [VOTE] for releasing Apache Commons Math 3.4.

 Note that since [math] now uses git, access to the tag is slightly
 different from other components. To clone a fresh tag, run this command
 (beware I have split it in 2 lines below):

   git clone https://git-wip-us.apache.org/repos/asf/commons-math.git \
 --branch MATH_3_4_RC1
 
 -1
 
 This is insufficient to identify the code; branches are not immutable.
 
 Most (all?) other Git projects use a URL which includes the hash.
 For example, a current Incubator vote includes the following:
 
 The Git commit ID is 94b42b85e80efd817f951326238864
 e37edc2cb0
 https://git-wip-us.apache.org/repos/asf?p=incubator-brooklyn.git;a=commit;h=94b42b85e80efd817f951326238864e37edc2cb0

The SHA1 is stored directly in the manifest, withing the distribution.
For this release candidate, it is

cf4a9d70c9ac24dd7196995390171150e4e56451

I agree I did not put it in the mail, but you can check it in the artifacts.

best regards,
Luc

 
 
 
 To verify the tag (as git does sign tags with GPG), use this:

   cd commons-math
   git tag -v MATH_3_4_RC1

 The site will be available in the staging area, it takes a few hours to
 transfer from my machine:
   http://commons.staging.apache.org/proper/commons-math/

 Distribution files:
   https://dist.apache.org/repos/dist/dev/commons/math/
 
 -1
 
 The revision number is needed in order to uniquely identify the
 artifacts being voted on.
 Alternatively, provide hashes.
 
 Maven artifacts:

 https://repository.apache.org/content/repositories/orgapachecommons-1066/org/apache/commons/commons-math3/3.4/


 [ ] +1 Release it.
 [ ] +0 Go ahead; I don't care.
 [ ] -0 There are a few minor glitches: ...
 [ ] -1 No, do not release it because ...
 
 -1
 
 The NOTICE file needs severe pruning.
 I don't think any of the attributions are required.
 
 This vote will close in 72 hours, at 2014-12-21T23:15:00Z (this is UTC
 time).

 best regards,
 Luc

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

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


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

Re: [VOTE][RC1] Release Commons Math 3.4

On 18 December 2014 at 23:56, Luc Maisonobe l...@spaceroots.org wrote:
Le 19/12/2014 00:50, sebb a écrit :
On 18 December 2014 at 23:19, Luc Maisonobe l...@spaceroots.org wrote:
This is a [VOTE] for releasing Apache Commons Math 3.4.

Note that since [math] now uses git, access to the tag is slightly
different from other components. To clone a fresh tag, run this command
(beware I have split it in 2 lines below):

git clone https://git-wip-us.apache.org/repos/asf/commons-math.git \
--branch MATH_3_4_RC1

-1

This is insufficient to identify the code; branches are not immutable.

Most (all?) other Git projects use a URL which includes the hash.
For example, a current Incubator vote includes the following:

The Git commit ID is 94b42b85e80efd817f951326238864
e37edc2cb0
https://git-wip-us.apache.org/repos/asf?p=incubator-brooklyn.git;a=commit;h=94b42b85e80efd817f951326238864e37edc2cb0

The SHA1 is stored directly in the manifest, withing the distribution.
For this release candidate, it is

cf4a9d70c9ac24dd7196995390171150e4e56451

I agree I did not put it in the mail, but you can check it in the artifacts.

The point is to be able to trace provenance from the VOTE to the
released artifacts.

Also to make it easy for the reviewers to be able to check the release
candidate without having to jump through hoops.

It is not clear to me how I can use the SHA1 hash to get the exact set
of files from Git that were used to create the release artifacts.

The VOTE email should include all the information needed to validate a release.

best regards,
Luc

To verify the tag (as git does sign tags with GPG), use this:

cd commons-math
git tag -v MATH_3_4_RC1

The site will be available in the staging area, it takes a few hours to
transfer from my machine:
http://commons.staging.apache.org/proper/commons-math/

Distribution files:
https://dist.apache.org/repos/dist/dev/commons/math/

-1

The revision number is needed in order to uniquely identify the
artifacts being voted on.
Alternatively, provide hashes.

Maven artifacts:

https://repository.apache.org/content/repositories/orgapachecommons-1066/org/apache/commons/commons-math3/3.4/

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

-1

The NOTICE file needs severe pruning.
I don't think any of the attributions are required.

This vote will close in 72 hours, at 2014-12-21T23:15:00Z (this is UTC
time).

best regards,
Luc

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

Re: [VOTE][RC1] Release Commons Math 3.4

2014-12-18 Thread Emmanuel Bourg

Le 19/12/2014 01:08, sebb a écrit :

 The VOTE email should include all the information needed to validate a 
 release.

You are right but this is exactly the kind of hassle that makes release
management tedious and discourages people from publishing releases. At
some point a balance has to be found between the expectations, and I
think publishing new releases is more important than posting a VOTE mail
with an encyclopedic precision.

IMHO Luc provided enough information to review the release properly.

Emmanuel Bourg


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

Re: [VOTE][RC1] Release Commons Math 3.4

If it's not done properly, why bother with a VOTE at all?

On 19 December 2014 at 00:51, Emmanuel Bourg ebo...@apache.org wrote:
 Le 19/12/2014 01:08, sebb a écrit :

 The VOTE email should include all the information needed to validate a 
 release.

 You are right but this is exactly the kind of hassle that makes release
 management tedious and discourages people from publishing releases. At
 some point a balance has to be found between the expectations, and I
 think publishing new releases is more important than posting a VOTE mail
 with an encyclopedic precision.

 IMHO Luc provided enough information to review the release properly.

 Emmanuel Bourg


 -
 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: [VOTE][RC1] Release Commons Math 3.4

On Thu, Dec 18, 2014 at 8:14 PM, sebb seb...@gmail.com wrote:

 If it's not done properly, why bother with a VOTE at all?


I'm with Sebb here. Yes, our release process is a PITA, but what Sebb is
asking for is what I expect as well. If you want me to evaluate a RC and
VOTE, please make my life and that of all the other reviewers, easier, not
harder.

Sometimes, I download the src zip and build, sometimes, I checkout the
tag...

FWIW, it should take a few minutes to transfer a site. Zip it, transfer it,
unzip it. One file at a time is asking for problems IMO. Or are you saying
that it takes hours to transfer even as a Zip?

Gary



 On 19 December 2014 at 00:51, Emmanuel Bourg ebo...@apache.org wrote:
  Le 19/12/2014 01:08, sebb a écrit :
 
  The VOTE email should include all the information needed to validate a
 release.
 
  You are right but this is exactly the kind of hassle that makes release
  management tedious and discourages people from publishing releases. At
  some point a balance has to be found between the expectations, and I
  think publishing new releases is more important than posting a VOTE mail
  with an encyclopedic precision.
 
  IMHO Luc provided enough information to review the release properly.
 
  Emmanuel Bourg
 
 
  -
  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



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE][RC1] Release Commons Math 3.4

2014-12-18 Thread Luc Maisonobe

Le 19/12/2014 03:25, Gary Gregory a écrit :
 On Thu, Dec 18, 2014 at 8:14 PM, sebb seb...@gmail.com wrote:

 If it's not done properly, why bother with a VOTE at all?

 
 I'm with Sebb here. Yes, our release process is a PITA, but what Sebb is
 asking for is what I expect as well. If you want me to evaluate a RC and
 VOTE, please make my life and that of all the other reviewers, easier, not
 harder.

So do you want me to cancel the vote, redo all the process just because
the *mail* did not include the SHA ? Or should I cancel the vote and
just relaunch it from the exact same artifacts (and hence still and RC1)
to make the tag retrieving process clearer?

By the way MATH_3_4_RC1 is really a tag, its not a branch despite the
command I suggested to retrieve it used the --branch option from git
clone; this option accepts both tags and branches. But I agree, even
tags in git can be deleted and recreated ... just like tags in svn which
can also be changed despite policy is to not do it. So in reality, there
is no less traceability here with a git tag than with a svn tag.
Furthermore, git tags can be GPG signed, which I did here.

 
 Sometimes, I download the src zip and build, sometimes, I checkout the
 tag...
 
 FWIW, it should take a few minutes to transfer a site. Zip it, transfer it,
 unzip it. One file at a time is asking for problems IMO. Or are you saying
 that it takes hours to transfer even as a Zip?

I tried to use the existing staging area for the site, so was stuck to
use svn, which does takes hours and in my case fails if the number of
files is too large. In any case, even if I first upload a zip in my area
on people.apache.org, I will have to use svn finally for updating the
real site, and hence I will have to go through this.

The real problem with my approach is that since the staging area is
share, the site went live earlier than expected, so it is already on the
main site by nown sorry for that. It is not really a problem since the
site is already updated from time to time, as users asked on the list to
have the development API online, so the current site was alread almost
the final one (it was last published in mid-October, two months ago).

So to avoid this, I'll go back to unpakc a zip on people.apache.org next
time.

best regards,
Luc


 
 Gary
 
 

 On 19 December 2014 at 00:51, Emmanuel Bourg ebo...@apache.org wrote:
 Le 19/12/2014 01:08, sebb a écrit :

 The VOTE email should include all the information needed to validate a
 release.

 You are right but this is exactly the kind of hassle that makes release
 management tedious and discourages people from publishing releases. At
 some point a balance has to be found between the expectations, and I
 think publishing new releases is more important than posting a VOTE mail
 with an encyclopedic precision.

 IMHO Luc provided enough information to review the release properly.

 Emmanuel Bourg


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


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


 


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

Re: [VOTE] Release Configuration 2.0-alpha2 based on RC1