[CANCELLED} [VOTE] Release Apache Commons RDF 0.5.0 based on RC2

[Sergio Fernández]

Thanks, Stian, that's exactlywas I was expecting.

So I formally CANCEL this VOTE, and I'll prepare a RC3 in the next few
days. includihe fix for COMMONSRDF-69..



On Wed, Dec 6, 2017 at 4:59 AM, Stian Soiland-Reyes 
wrote:

> Good effort, Sergio! Sorry for late review.
> I guess you didn't get to many replies as there was confusion with the
> dist/svn revision.. :-(
>
>
> Sorry, my vote is -1 (binding)
>
> .. as META-INF/LICENSE and META-INF/NOTICE are missing in the binary
> JARs in the maven repo.
>
> (Not sure how I missed this before, is this caused by a change in
> commons-parent affecting submodules?)
>
>
> +1 gpg signatures dist & staging
> +1 dist svn (revision 23205 and 23227 are equal in this subtree)
> +1 git commit == tag ~= dist ~= staging  (except .gitignore / .travis.yml)
> -0 NOTICE has wrong Copyright year
> +1 builds with mvn clean install -T1.0C
> -1 META-INF/LICENSE and META-INF/NOTICE missing from JARs (except -api
> and -impl)
>
>
> Built with:
>
> Apache Maven 3.3.9
> Maven home: /usr/share/maven
> Java version: 1.8.0_151, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.10.0-40-generic", arch: "amd64", family:
> "unix"
>
> On 4 December 2017 at 11:13, Sergio Fernández  wrote:
> > I'd like to bring up this vote, which is waiting for votes for two weeks
> :-/
> >
> >
> > On Nov 26, 2017 13:21, "Sergio Fernández"  wrote:
> >
> > I'd like to ask the Commons PMC to cast a, any, vote for this RC. Because
> > it's stuck. It's fine to get -1s, but at least something to move forward.
> > Thanks.
> >
> > On Nov 22, 2017 17:52, "Sergio Fernández"  wrote:
> >
> >> Hi Oliver,
> >>
> >> thanks for the feedback on RC2. Please, find my answers inline.
> >>
> >> On Wed, Nov 22, 2017 at 1:25 PM, Oliver Heger <
> >> oliver.he...@oliver-heger.de> wrote:
> >>>
> >>> [ERROR] Failed to execute goal
> >>> org.apache.maven.plugins:maven-site-plugin:3.6:site (default-cli) on
> >>> project commons-rdf-parent: Error generating
> >>> maven-checkstyle-plugin:2.12.1:checkstyle-aggregate: Failed during
> >>> checkstyle configuration: cannot initialize module TreeWalker -
> Property
> >>> 'ignoreAnnotationCanonicalNames' in module VisibilityModifier does not
> >>> exist, please check the documentation -> [Help 1]
> >>>
> >>> A problem with the version of the checkstyle plugin?
> >>>
> >>
> >>  Maybe..., the version comes from Commons Parent. The issue is that I'm
> >> not able to reproduce the problem in Unix, neither in Linux nor OSX.
> >>
> >> Some other notes:
> >>> * NOTICE has the wrong copyright year. I think this needs to be fixed.
> >>>
> >>
> >> Yeah, I reported that as https://issues.apache.org/j
> >> ira/browse/COMMONSRDF-69
> >>
> >>
> >>> * The project does not release binary artifacts. This is probably okay,
> >>> but unusual for Commons. It would be nice if you could add a binary
> >>> distribution - maybe for the 1.0 release.
> >>>
> >>
> >> Afterwards I updated the vote to include the binary release, too:
> >>
> >> https://lists.apache.org/thread.html/23cf46d92c2afa191690edc
> >> a5ea76c0882c108c1a9dc1709a9d9ee52@%3Cdev.commons.apache.org%3E
> >>
> >> Thanks.
> >>
> >>
> >>
> >> Am 19.11.2017 um 23:08 schrieb Sergio Fernández:
> >> > Hi,
> >> >
> >> > once we addressed most of the issues from RC1, I'd like to propose to
> >> > release Apache Commons RDF 0.5.0 based on RC2.
> >> >
> >> > Apache Commons RDF aims to provide a common Java API for RDF 1.1
> graphs
> >> and
> >> > datasets. API bindings in Commons RDF 0.5.0 include Apache Jena,
> Eclipse
> >> > RDF4J, JSON-LD Java as well as a standalone implementation (simple).
> >> >
> >> > Apache Commons RDF 0.5.0 RC2 is available for review at (r23205):
> >> >
> >> > https://dist.apache.org/repos/dist/dev/commons/rdf/apache-co
> >> mmons-rdf-0.5.0-RC2/
> >> >
> >> > The source code for this RC is available from git tagged as 0.5.0-RC2
> >> > (commit 186df0c36981a308338792f02d93fc59776b0b7c):
> >> >
> >> > https://git-wip-us.apache.org/repos/asf?p=commons-rdf.git;a=
> >> commit;h=186df0c36981a308338792f02d93fc59776b0b7c
> >> >
> >> > Mirrored at
> >> > https://github.com/apache/commons-rdf/commit/186df0c36981a30
> >> 8338792f02d93fc59776b0b7c
> >> >
> >> > This source release produces the following binary artifacts:
> >> >
> >> > commons-rdf-parent-0.5.0
> >> > commons-rdf-api-0.5.0
> >> > commons-rdf-simple-0.5.0
> >> > commons-rdf-jena-0.5.0
> >> > commons-rdf-rdf4j-0.5.0
> >> > commons-rdf-jsonld-java-0.5.0
> >> > commons-rdf-integration-tests-0.5.0
> >> >
> >> > The Maven Staging repository can be found at:
> >> >
> >> > https://repository.apache.org/content/repositories/
> orgapachecommons-1293
> >> >
> >> > Please vote on releasing this release candidate as:
> >> >
> >> > Apache Commons RDF 0.5.0
> >> >
> >> > The vote is open for at least 72 hours/
> >> >
> 

Re: [VOTE] Release Apache Commons BCEL based on RC1

[Gary Gregory]

Oliver, how do you feel about installing Java 9 and trying again?

Gary

On Tue, Dec 5, 2017 at 1:48 PM, Gary Gregory  wrote:

> The test calls the registryGetKeys Windows API and that throws an
> exception because Java 9 is not installed on that machine. This is a bug in
> the test only. Fixed in trunk. Not a showstopper IMO.
>
> Gary
>
> On Sun, Dec 3, 2017 at 1:44 PM, Oliver Heger  > wrote:
>
>> Here is the stack trace:
>>
>> 
>> ---
>> Test set: org.apache.bcel.generic.JDKGenericDumpTestCase
>> 
>> ---
>> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.657
>> sec <<< FAILURE! - in org.apache.bcel.generic.JDKGenericDumpTestCase
>> initializationError(org.apache.bcel.generic.JDKGenericDumpTestCase)
>> Time elapsed: 0 sec  <<< ERROR!
>> com.sun.jna.platform.win32.Win32Exception: Das System kann die
>> angegebene Datei nicht finden.
>> at
>> org.apache.bcel.generic.JDKGenericDumpTestCase.addAllJavaHom
>> esOnWindows(JDKGenericDumpTestCase.java:65)
>> at
>> org.apache.bcel.generic.JDKGenericDumpTestCase.findJavaHomes
>> OnWindows(JDKGenericDumpTestCase.java:97)
>> at
>> org.apache.bcel.generic.JDKGenericDumpTestCase.findJavaHomes
>> (JDKGenericDumpTestCase.java:87)
>> at
>> org.apache.bcel.generic.JDKGenericDumpTestCase.data(JDKGener
>> icDumpTestCase.java:82)
>>
>> Oliver
>>
>> Am 03.12.2017 um 16:58 schrieb Gary Gregory:
>> > Do you have a full stack trace? It smells like the code that looks for
>> JDK
>> > and JRE locations is failing.
>> >
>> > Gary
>> >
>> > On Dec 3, 2017 08:33, "Oliver Heger" 
>> wrote:
>> >
>> >> Hi,
>> >>
>> >> when building on Windows 10 with both Java 1.7 and 1.8 I get the test
>> >> failure below. Does anybody else see this?
>> >>
>> >> Oliver
>> >>
>> >> Results :
>> >>
>> >> Tests in error:
>> >>
>> >> JDKGenericDumpTestCase.data:82->findJavaHomes:87->
>> >> findJavaHomesOnWindows:97->addAllJavaHomesOnWindows:65
>> >> ▒ Win32
>> >>
>> >> Tests run: 107, Failures: 0, Errors: 1, Skipped: 0
>> >>
>> >> $ mvn --version
>> >> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
>> >> 2015-11-10T17:41:47+01:00)
>> >> Maven home: C:\data\dev\tools\apache-maven-3.3.9
>> >> Java version: 1.8.0_144, vendor: Oracle Corporation
>> >> Java home: C:\Program Files\Java\jdk1.8.0_144\jre
>> >> Default locale: de_DE, platform encoding: Cp1252
>> >> OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"
>> >>
>> >>
>> >> Am 01.12.2017 um 05:17 schrieb Gary Gregory:
>> >>> We fixed a few bugs and added some enhancements since we released
>> Apache
>> >>> Commons BCEL 6.1, so I would like to release Commons BCEL 6.2.
>> >>>
>> >>> Commons BCEL 6.2 RC1 is available for review here:
>> >>> https://dist.apache.org/repos/dist/dev/commons/bcel at svn
>> revision:
>> >>> 23349
>> >>>
>> >>> The tag is here:
>> >>> http://svn.apache.org/repos/asf/commons/proper/bcel/tags/
>> >> BCEL_6_2_RC1/
>> >>> (svn revision 1816763)
>> >>> N.B. the SVN revision is required because SVN tags are not
>> immutable.
>> >>>
>> >>> Maven artifacts are here:
>> >>> https://repository.apache.org/content/repositories/
>> >> orgapachecommons-1294
>> >>>
>> >>> These are the Maven artifacts and their hashes
>> >>>
>> >>> /org/apache/bcel/bcel/6.2/bcel-6.2-test-sources.jar
>> >>> (SHA1: feef9dc39b67bf76d90a16abf3b5711d894bdafc)
>> >>> /org/apache/bcel/bcel/6.2/bcel-6.2.jar.asc
>> >>> (SHA1: 10911db34eabbf5ed77175147d890431815a66e9)
>> >>> /org/apache/bcel/bcel/6.2/bcel-6.2-tests.jar.asc
>> >>> (SHA1: dd32ec245d2d664ee69a70bde304df5f577c3e8b)
>> >>> /org/apache/bcel/bcel/6.2/bcel-6.2-src.tar.gz.asc
>> >>> (SHA1: 1b6562ffec86267c8d1935dc1fa33c0fd225a094)
>> >>> /org/apache/bcel/bcel/6.2/bcel-6.2-bin.tar.gz.asc
>> >>> (SHA1: b7c31d213469b4044361b780890732f67859ec7e)
>> >>> /org/apache/bcel/bcel/6.2/bcel-6.2-bin.zip.asc
>> >>> (SHA1: 7137b7dfbc135aed1b2f8c7c974289e5ad645e3b)
>> >>> /org/apache/bcel/bcel/6.2/bcel-6.2-tests.jar
>> >>> (SHA1: 9de7ca4bbce76f7a877700ffc88bc2e36ef065ea)
>> >>> /org/apache/bcel/bcel/6.2/bcel-6.2-javadoc.jar
>> >>> (SHA1: 6eba2e55001a6093c8a9aa72132385e93fbe09d3)
>> >>> /org/apache/bcel/bcel/6.2/bcel-6.2-sources.jar
>> >>> (SHA1: df05f2afa0f58aefe5c3344fc67295ffc2050d53)
>> >>> /org/apache/bcel/bcel/6.2/bcel-6.2-test-sources.jar.asc
>> >>> (SHA1: 4999bb9f6d5ad677f13f1e5e856f8a76fdf3c8fc)
>> >>> /org/apache/bcel/bcel/6.2/bcel-6.2.pom.asc
>> >>> (SHA1: 6fd1c5c4fbc96b83f06c421a99fc3ee7f975c310)
>> >>> /org/apache/bcel/bcel/6.2/bcel-6.2.jar
>> >>> (SHA1: 2c1499b28bf2638cbdb5fa94350d41a46d2bd4e0)
>> >>> /org/apache/bcel/bcel/6.2/bcel-6.2-bin.tar.gz
>> >>> (SHA1: 9116cfccfb5f55a5a9e46fb685c7aa344712d52e)
>> >>> /org/apache/bcel/bcel/6.2/bcel-6.2-src.zip.asc
>> >>> (SHA1: 

Re: [VOTE] Release Apache Commons RDF 0.5.0 based on RC2

[ajs6f]

Stian-- 

Just a quick technical question (really my own curiosity): I see you built with 
`mvn clean install -T1.0C` (explicitly calling out the thread count). Is that 
for reproducibility or some other reason?

ajs6f

> On Dec 6, 2017, at 7:59 AM, Stian Soiland-Reyes  wrote:
> 
> Good effort, Sergio! Sorry for late review.
> I guess you didn't get to many replies as there was confusion with the
> dist/svn revision.. :-(
> 
> 
> Sorry, my vote is -1 (binding)
> 
> .. as META-INF/LICENSE and META-INF/NOTICE are missing in the binary
> JARs in the maven repo.
> 
> (Not sure how I missed this before, is this caused by a change in
> commons-parent affecting submodules?)
> 
> 
> +1 gpg signatures dist & staging
> +1 dist svn (revision 23205 and 23227 are equal in this subtree)
> +1 git commit == tag ~= dist ~= staging  (except .gitignore / .travis.yml)
> -0 NOTICE has wrong Copyright year
> +1 builds with mvn clean install -T1.0C
> -1 META-INF/LICENSE and META-INF/NOTICE missing from JARs (except -api
> and -impl)
> 
> 
> Built with:
> 
> Apache Maven 3.3.9
> Maven home: /usr/share/maven
> Java version: 1.8.0_151, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
> Default locale: en_GB, platform encoding: UTF-8
> OS name: "linux", version: "4.10.0-40-generic", arch: "amd64", family: "unix"
> 
> On 4 December 2017 at 11:13, Sergio Fernández  wrote:
>> I'd like to bring up this vote, which is waiting for votes for two weeks :-/
>> 
>> 
>> On Nov 26, 2017 13:21, "Sergio Fernández"  wrote:
>> 
>> I'd like to ask the Commons PMC to cast a, any, vote for this RC. Because
>> it's stuck. It's fine to get -1s, but at least something to move forward.
>> Thanks.
>> 
>> On Nov 22, 2017 17:52, "Sergio Fernández"  wrote:
>> 
>>> Hi Oliver,
>>> 
>>> thanks for the feedback on RC2. Please, find my answers inline.
>>> 
>>> On Wed, Nov 22, 2017 at 1:25 PM, Oliver Heger <
>>> oliver.he...@oliver-heger.de> wrote:
 
 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-site-plugin:3.6:site (default-cli) on
 project commons-rdf-parent: Error generating
 maven-checkstyle-plugin:2.12.1:checkstyle-aggregate: Failed during
 checkstyle configuration: cannot initialize module TreeWalker - Property
 'ignoreAnnotationCanonicalNames' in module VisibilityModifier does not
 exist, please check the documentation -> [Help 1]
 
 A problem with the version of the checkstyle plugin?
 
>>> 
>>> Maybe..., the version comes from Commons Parent. The issue is that I'm
>>> not able to reproduce the problem in Unix, neither in Linux nor OSX.
>>> 
>>> Some other notes:
 * NOTICE has the wrong copyright year. I think this needs to be fixed.
 
>>> 
>>> Yeah, I reported that as https://issues.apache.org/j
>>> ira/browse/COMMONSRDF-69
>>> 
>>> 
 * The project does not release binary artifacts. This is probably okay,
 but unusual for Commons. It would be nice if you could add a binary
 distribution - maybe for the 1.0 release.
 
>>> 
>>> Afterwards I updated the vote to include the binary release, too:
>>> 
>>> https://lists.apache.org/thread.html/23cf46d92c2afa191690edc
>>> a5ea76c0882c108c1a9dc1709a9d9ee52@%3Cdev.commons.apache.org%3E
>>> 
>>> Thanks.
>>> 
>>> 
>>> 
>>> Am 19.11.2017 um 23:08 schrieb Sergio Fernández:
 Hi,
 
 once we addressed most of the issues from RC1, I'd like to propose to
 release Apache Commons RDF 0.5.0 based on RC2.
 
 Apache Commons RDF aims to provide a common Java API for RDF 1.1 graphs
>>> and
 datasets. API bindings in Commons RDF 0.5.0 include Apache Jena, Eclipse
 RDF4J, JSON-LD Java as well as a standalone implementation (simple).
 
 Apache Commons RDF 0.5.0 RC2 is available for review at (r23205):
 
 https://dist.apache.org/repos/dist/dev/commons/rdf/apache-co
>>> mmons-rdf-0.5.0-RC2/
 
 The source code for this RC is available from git tagged as 0.5.0-RC2
 (commit 186df0c36981a308338792f02d93fc59776b0b7c):
 
 https://git-wip-us.apache.org/repos/asf?p=commons-rdf.git;a=
>>> commit;h=186df0c36981a308338792f02d93fc59776b0b7c
 
 Mirrored at
 https://github.com/apache/commons-rdf/commit/186df0c36981a30
>>> 8338792f02d93fc59776b0b7c
 
 This source release produces the following binary artifacts:
 
 commons-rdf-parent-0.5.0
 commons-rdf-api-0.5.0
 commons-rdf-simple-0.5.0
 commons-rdf-jena-0.5.0
 commons-rdf-rdf4j-0.5.0
 commons-rdf-jsonld-java-0.5.0
 commons-rdf-integration-tests-0.5.0
 
 The Maven Staging repository can be found at:
 
 https://repository.apache.org/content/repositories/orgapachecommons-1293
 
 Please vote on releasing this release candidate as:
 
 Apache Commons RDF 0.5.0
 
 The vote is open for at least 72 hours/
 
 [ ] +1 Release this package
 [ ] 0 I don't 

Re: [All][Math] New component: "Commons Geometry"?

[Stephen Colebourne]

Frankly, as an observer, this issue seems to be handled pretty poorly.
Commons-Math is currently dead. There are people willing to put in
effort to work on parts of it, but they are blocked at every turn.
Various options are put forward, but nothing ever happens.

In technical terms, if Commons-Math were a TLP, it would no doubt
release multiple separate releases, just like commons does. Thus,
separate commons projects seems like a good model.

Commons-VFS is not a good comparator, as it is a single "narrow and
deep" library with plugins. Commons-Math is a "broad and shallow"
library by comparison [1]. Subdivisions of a "broad and shallow"
library are best managed with separate release cycles, as each part is
independent of the others. (commons [lang], [collections] and [io] are
not forced to be multi-module simply because they all release to the
java.base module).

Anyway, the original rules for Commons [2] required a majority
approval vote (more +1 than -1) to create a new component, which has
already happended AFAICT. So, I think those that want to create a new
component should JFDI.

Stephen


[1] https://marc.info/?l=jakarta-commons-dev=108601577728628=2
[2] http://commons.apache.org/oldcharter.html (item 15)



On 6 December 2017 at 12:59, Gilles  wrote:
> Hi Ralph.
>
> On Tue, 5 Dec 2017 22:38:06 -0700, Ralph Goers wrote:
>>
>> I don’t know
>
>
> Then please _read_ the ML archive.
>
>> why you are ignoring
>
>
> I do not (willingly) "ignore" any proposal. [Gentle
> reminders are welcome if/when I lost track of a pending
> issue that is waiting for my input.]
>
> It's rather the opposite: a few PMC people keep turning
> a blind eye to arguably constructive proposals (see below
> and ML archive).
>
>> option 3, which is what many have
>> suggested many times.
>
>
> With strings attached. See ML archive.
>
>> 3) Modify CM to be a multi-module project
>
>
> See below; what don't you understand in "issues which
> maven modules will not solve"?
> [See ML archive for a many times reiterated detailed
> description of the CM problems, the difference between
> CM and other components (modular or not), here and
> elsewhere, and how we do not have (never had) the human
> resources to correctly handle such a large and diverse
> code base.]
>
>> that contains only the
>> modules you want to support.
>
>
> That condition was explicitly rejected  when *I* first
> evoked it (see ML archive).
>
> Later discussions (see ML archive) clarified (?!) that
> modularizing CM would certainly not suffice to revive
> the project.
>
> Other options were (see ML archive)
> 4. create an Apache TLP (proposed by James Carman),
> 5. go through the Incubator.
>
> Either one required the PMC to relinquish the code base
> (no internal fork allowed IIUC), which it refused (see ML
> archive).
>
> The now visible consequences of renewed obstruction to
> the refactoring of CM were not difficult to predict (see
> ML archive).
>
> Gilles
>
>
>
>> Ralph
>>
>>> On Dec 3, 2017, at 4:51 AM, Gilles  wrote:
>>>
>>> On Sun, 3 Dec 2017 11:18:18 +0100, Jochen Wiedmann wrote:

 On Fri, Dec 1, 2017 at 2:26 PM, Gilles 
 wrote:

> There hasn't been any progress towards a decision.
> There isn't even a consensus on one of the central tenets of
> Apache ("Those who do the work..."): how sad/strange (?).


 Those who do the work are welcome to decide on their own, if they do
 not involve others.
>>>
>>>
>>> The conditional is not part of the well-known mantra.
>>>
>>> The issue here is to answer the question of what to do with
>>> a non-trivial code base.  My stance is to try and fix the
>>> problem(s), a.o. difficult management, by rooting out its
>>> main cause: CM has become an aggregate of components with
>>> completely different subject matters, scopes, designs,
>>> efficiencies, provisions for extension, etc.
>>> [An array of issues which "maven" modules will not solve.]
>>>
>>> We are seemingly faced with a choice between:
>>> 1. Maintain CM as the huge library that it is now.
>>> 2. Incrementally create maintainable components.
>>>
>>> A long time has passed since these alternatives were first
>>> exposed, only proving that none of the people who informally
>>> chose option(1) invested work to make it a reality.
>>>
>>> Refusing option (2) not only "involves others"; it is harming
>>> them (very real people, having done a lot of work here, on
>>> that code base).
>>>
 Establishing a new commons component doesn't
 qualify, IMO.
>>>
>>>
>>> True; that's why we are stalled, despite that a majority
>>> of the PMC did not explicitly oppose option (2).
>>>
>>> A handful of PMC people prefer to let the code base become
>>> "dormant" rather than give any chance to an alternate view.
>>> [If, say, you looked at the "Commons RNG" project, and
>>> concluded that, decidedly, this is not how a component
>>> should look 

Re: [GitHub][JEXL] Svn trunk no longer reflected in Git ?

[henrib]

Opened INFRA-15611 (syncing to GitHub) & INFRA-15612 (creating a writeable
GitHub repo).



--
Sent from: http://apache-commons.680414.n4.nabble.com/Commons-Dev-f680415.html

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

Re: [VOTE] Release Apache Commons RDF 0.5.0 based on RC2

[Stian Soiland-Reyes]

Good effort, Sergio! Sorry for late review.
I guess you didn't get to many replies as there was confusion with the
dist/svn revision.. :-(


Sorry, my vote is -1 (binding)

.. as META-INF/LICENSE and META-INF/NOTICE are missing in the binary
JARs in the maven repo.

(Not sure how I missed this before, is this caused by a change in
commons-parent affecting submodules?)


+1 gpg signatures dist & staging
+1 dist svn (revision 23205 and 23227 are equal in this subtree)
+1 git commit == tag ~= dist ~= staging  (except .gitignore / .travis.yml)
-0 NOTICE has wrong Copyright year
+1 builds with mvn clean install -T1.0C
-1 META-INF/LICENSE and META-INF/NOTICE missing from JARs (except -api
and -impl)


Built with:

Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.8.0_151, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.10.0-40-generic", arch: "amd64", family: "unix"

On 4 December 2017 at 11:13, Sergio Fernández  wrote:
> I'd like to bring up this vote, which is waiting for votes for two weeks :-/
>
>
> On Nov 26, 2017 13:21, "Sergio Fernández"  wrote:
>
> I'd like to ask the Commons PMC to cast a, any, vote for this RC. Because
> it's stuck. It's fine to get -1s, but at least something to move forward.
> Thanks.
>
> On Nov 22, 2017 17:52, "Sergio Fernández"  wrote:
>
>> Hi Oliver,
>>
>> thanks for the feedback on RC2. Please, find my answers inline.
>>
>> On Wed, Nov 22, 2017 at 1:25 PM, Oliver Heger <
>> oliver.he...@oliver-heger.de> wrote:
>>>
>>> [ERROR] Failed to execute goal
>>> org.apache.maven.plugins:maven-site-plugin:3.6:site (default-cli) on
>>> project commons-rdf-parent: Error generating
>>> maven-checkstyle-plugin:2.12.1:checkstyle-aggregate: Failed during
>>> checkstyle configuration: cannot initialize module TreeWalker - Property
>>> 'ignoreAnnotationCanonicalNames' in module VisibilityModifier does not
>>> exist, please check the documentation -> [Help 1]
>>>
>>> A problem with the version of the checkstyle plugin?
>>>
>>
>>  Maybe..., the version comes from Commons Parent. The issue is that I'm
>> not able to reproduce the problem in Unix, neither in Linux nor OSX.
>>
>> Some other notes:
>>> * NOTICE has the wrong copyright year. I think this needs to be fixed.
>>>
>>
>> Yeah, I reported that as https://issues.apache.org/j
>> ira/browse/COMMONSRDF-69
>>
>>
>>> * The project does not release binary artifacts. This is probably okay,
>>> but unusual for Commons. It would be nice if you could add a binary
>>> distribution - maybe for the 1.0 release.
>>>
>>
>> Afterwards I updated the vote to include the binary release, too:
>>
>> https://lists.apache.org/thread.html/23cf46d92c2afa191690edc
>> a5ea76c0882c108c1a9dc1709a9d9ee52@%3Cdev.commons.apache.org%3E
>>
>> Thanks.
>>
>>
>>
>> Am 19.11.2017 um 23:08 schrieb Sergio Fernández:
>> > Hi,
>> >
>> > once we addressed most of the issues from RC1, I'd like to propose to
>> > release Apache Commons RDF 0.5.0 based on RC2.
>> >
>> > Apache Commons RDF aims to provide a common Java API for RDF 1.1 graphs
>> and
>> > datasets. API bindings in Commons RDF 0.5.0 include Apache Jena, Eclipse
>> > RDF4J, JSON-LD Java as well as a standalone implementation (simple).
>> >
>> > Apache Commons RDF 0.5.0 RC2 is available for review at (r23205):
>> >
>> > https://dist.apache.org/repos/dist/dev/commons/rdf/apache-co
>> mmons-rdf-0.5.0-RC2/
>> >
>> > The source code for this RC is available from git tagged as 0.5.0-RC2
>> > (commit 186df0c36981a308338792f02d93fc59776b0b7c):
>> >
>> > https://git-wip-us.apache.org/repos/asf?p=commons-rdf.git;a=
>> commit;h=186df0c36981a308338792f02d93fc59776b0b7c
>> >
>> > Mirrored at
>> > https://github.com/apache/commons-rdf/commit/186df0c36981a30
>> 8338792f02d93fc59776b0b7c
>> >
>> > This source release produces the following binary artifacts:
>> >
>> > commons-rdf-parent-0.5.0
>> > commons-rdf-api-0.5.0
>> > commons-rdf-simple-0.5.0
>> > commons-rdf-jena-0.5.0
>> > commons-rdf-rdf4j-0.5.0
>> > commons-rdf-jsonld-java-0.5.0
>> > commons-rdf-integration-tests-0.5.0
>> >
>> > The Maven Staging repository can be found at:
>> >
>> > https://repository.apache.org/content/repositories/orgapachecommons-1293
>> >
>> > Please vote on releasing this release candidate as:
>> >
>> > Apache Commons RDF 0.5.0
>> >
>> > The vote is open for at least 72 hours/
>> >
>> > [ ] +1 Release this package
>> > [ ] 0 I don't feel strongly about it, but don't object
>> > [ ] -1 Do not release this package because...
>> >
>> > Anyone can participate in testing and voting, not just committers,
>> > please feel free to try out the release candidate and provide your
>> > votes!
>> >
>> > Thanks
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: 

Re: [All][Math] New component: "Commons Geometry"?

[Gilles]

Hi Ralph.

On Tue, 5 Dec 2017 22:38:06 -0700, Ralph Goers wrote:

I don’t know


Then please _read_ the ML archive.


why you are ignoring


I do not (willingly) "ignore" any proposal. [Gentle
reminders are welcome if/when I lost track of a pending
issue that is waiting for my input.]

It's rather the opposite: a few PMC people keep turning
a blind eye to arguably constructive proposals (see below
and ML archive).


option 3, which is what many have
suggested many times.


With strings attached. See ML archive.


3) Modify CM to be a multi-module project


See below; what don't you understand in "issues which
maven modules will not solve"?
[See ML archive for a many times reiterated detailed
description of the CM problems, the difference between
CM and other components (modular or not), here and
elsewhere, and how we do not have (never had) the human
resources to correctly handle such a large and diverse
code base.]


that contains only the
modules you want to support.


That condition was explicitly rejected  when *I* first
evoked it (see ML archive).

Later discussions (see ML archive) clarified (?!) that
modularizing CM would certainly not suffice to revive
the project.

Other options were (see ML archive)
4. create an Apache TLP (proposed by James Carman),
5. go through the Incubator.

Either one required the PMC to relinquish the code base
(no internal fork allowed IIUC), which it refused (see ML
archive).

The now visible consequences of renewed obstruction to
the refactoring of CM were not difficult to predict (see
ML archive).

Gilles



Ralph

On Dec 3, 2017, at 4:51 AM, Gilles  
wrote:


On Sun, 3 Dec 2017 11:18:18 +0100, Jochen Wiedmann wrote:
On Fri, Dec 1, 2017 at 2:26 PM, Gilles 
 wrote:



There hasn't been any progress towards a decision.
There isn't even a consensus on one of the central tenets of
Apache ("Those who do the work..."): how sad/strange (?).


Those who do the work are welcome to decide on their own, if they 
do

not involve others.


The conditional is not part of the well-known mantra.

The issue here is to answer the question of what to do with
a non-trivial code base.  My stance is to try and fix the
problem(s), a.o. difficult management, by rooting out its
main cause: CM has become an aggregate of components with
completely different subject matters, scopes, designs,
efficiencies, provisions for extension, etc.
[An array of issues which "maven" modules will not solve.]

We are seemingly faced with a choice between:
1. Maintain CM as the huge library that it is now.
2. Incrementally create maintainable components.

A long time has passed since these alternatives were first
exposed, only proving that none of the people who informally
chose option(1) invested work to make it a reality.

Refusing option (2) not only "involves others"; it is harming
them (very real people, having done a lot of work here, on
that code base).


Establishing a new commons component doesn't
qualify, IMO.


True; that's why we are stalled, despite that a majority
of the PMC did not explicitly oppose option (2).

A handful of PMC people prefer to let the code base become
"dormant" rather than give any chance to an alternate view.
[If, say, you looked at the "Commons RNG" project, and
concluded that, decidedly, this is not how a component
should look like, then I could perhaps fathom out where
those reservations come from.]

Gilles



Jochen



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