You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commonsrdf.apache.org by Sergio Fernández <wi...@apache.org> on 2015/05/07 16:27:35 UTC
[VOTE] Release Apache Commons RDF 0.1.0-incubating RC2
Hello
I am pleased to be calling this vote for the source release of Apache
Commons RDF 0.1.0-incubating, composed by:
* commons-rdf-api 0.1.0-incubating
* commons-rdf-simple 0.1.0-incubating
A candidate for the Commons RDF 0.1.0-incubating release is available at:
https://dist.apache.org/repos/dist/dev/incubator/commonsrdf/0.1.0-incubating/
The release candidate is based on the sources from commit
454ebc1ff457bcdb34f4671565bc984e6fbbcb77, tagged as 0.1.0-incubating, at:
https://git-wip-us.apache.org/repos/asf/incubator-commonsrdf.git
Release artifacts are signed with the keys available at:
https://dist.apache.org/repos/dist/release/incubator/commonsrdf/KEYS
A staged Maven repository is available for review at:
https://repository.apache.org/content/repositories/orgapachecommons-1095
The changelog for this version is available from JIRA:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316620&version=12332056
Please vote on releasing this package as Apache Commons RDF
0.1.0-incubating. The vote is open for at least 72 hours and passes if a
majority of at least three +1 IPMC votes are cast.
[ ] +1 Release this package
[ ] 0 I don't feel strongly about it, but I'm okay with the release
[ ] -1 Do not release this package because...
--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernandez@redlink.co
w: http://redlink.co
Re: [VOTE] Release Apache Commons RDF 0.1.0-incubating RC2
Posted by Stian Soiland-Reyes <st...@apache.org>.
So you think we need a new RC to include the byte-equal LICENSE? Or can we
just mention this in the VOTE?
I don't know where the "broken" LICENSE came from, but from the diff you
see there are no semantic differences.
On 8 May 2015 16:09, "John D. Ament" <jo...@apache.org> wrote:
> If we can include that in the release, it'll save us some concerns on the
> general list vote.
>
> John
>
> On Thu, May 7, 2015 at 12:56 PM Stian Soiland-Reyes <st...@apache.org>
> wrote:
>
> > I committed fixed LICENSE (s) retrieved from
> > https://www.apache.org/licenses/LICENSE-2.0.txt which changed some
> > other formatting -- which I don't think is a legal issue or blocker
> > for this release.
> >
> >
> >
> https://github.com/apache/incubator-commonsrdf/commit/90b85287a67d3b64ecc83469de5dbbd1fdf7dce2
> >
> >
> > Inclusion of src/site/resources/css indicates you didn't create the
> > release from a fresh git check-out, which I would strongly recommend
> > for the future. Starting with an empty ~/.m2/repository is also good
> > practice.
> >
> >
> > Thanks for preparing the release candidate!
> >
> > On 7 May 2015 at 17:49, Stian Soiland-Reyes <st...@apache.org> wrote:
> > > +1 (PPMC binding, IPMC non-binding)
> > >
> > >
> > > * Verified signatures from KEYS
> > > * Verified sha1/md5 (perhaps these should also be included in email?)
> > > fd70a39de363c669744393c57b2fb8f90b15d3c1
> > > d245c016612632964b070829aa5079c9ed8d2e9b
> > > * zip and tar.gz content match 100%
> > > * zip/tar.gz content matches git tag
> > > 454ebc1ff457bcdb34f4671565bc984e6fbbcb77 - except:
> > > + examples/ missing from archive -- OK for now - but why not
> include
> > it?
> > > + empty folder src/site/resources/css in zip -- not quite OK, but
> > > I'll let it pass as it is empty
> > > * builds with mvn clean install
> > > * mvn apache-rat:check passes
> > > * No binaries (except png and xcf)
> > > * Includes NOTICE and LICENSE -- however the first line of LICENSE
> > > looks a bit odd as some whitespace seems removed. Fix for next
> > > version.
> > > * META-INF/NOTICE and META-INF/LICENSE correctly included in *.jar
> > artifacts
> > > * Dependencies have acceptable licenses, and do not need to be listed
> > > in NOTICE. Checked with mvn license:aggregate-add-third-party (see
> > > below)
> > >
> > >
> > > I've thrown in a bit of extra checks for good measures :)
> > >
> > > * Runs with the modified examples/pom.xml (had to be checked out from
> > git)
> > > * Staged repository works with the examples/ with a blank
> .m2/repository/
> > > * Filenames of api and simple *.jar from Maven staging repositories
> > > matches what gets compiled in */target (I didn't compare beyond
> > > filenames)
> > >
> > >
> > >
> > >
> > > Licenses:
> > >
> > > Lists of 3 third-party dependencies.
> > > (Eclipse Public License 1.0) JUnit (junit:junit:4.12 -
> > http://junit.org)
> > > (The Apache Software License, Version 2.0) Commons RDF: API
> > > (org.apache.commons:commons-rdf-api:0.1.0-incubating -
> > > http://commonsrdf.incubator.apache.org/commons-rdf-api)
> > > (New BSD License) Hamcrest Core (org.hamcrest:hamcrest-core:1.3 -
> > > https://github.com/hamcrest/JavaHamcrest/hamcrest-core)
> > >
> > >
> > >
> > > build tested on On Ubuntu 15.04 x64 with:
> > >
> > > stain@biggie-utopic:/tmp/92/
> >
> dist.apache.org/repos/dist/dev/incubator/commonsrdf/0.1.0-incubating/1/apache-commons-rdf-0.1.0-incubating$
> > > mvn -v
> > > Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar
> > > Apache Maven 3.3.1 (cab6659f9874fa96462afef40fcf6bc033d58c1c;
> > > 2015-03-13T20:10:27+00:00)
> > > Maven home: /home/stain/software/maven
> > > Java version: 1.8.0_45-internal, 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: "3.19.0-15-generic", arch: "amd64", family:
> > "unix"
> > >
> > >
> > >
> > >
> > >
> > >
> > > Here's another strange thing that is probably also called by settings
> > > in the parent pom:
> > >
> > >
> > >
> > >
> > > stain@biggie-utopic:/tmp/92/
> >
> dist.apache.org/repos/dist/dev/incubator/commonsrdf/0.1.0-incubating/2/apache-commons-rdf-0.1.0-incubating/simple$
> > > ls -al target/*jar
> > > -rw-rw-r-- 1 stain stain 18873 May 7 17:37
> target/apache-commons-rdf.jar
> > > -rw-rw-r-- 1 stain stain 35337 May 7 17:37
> > > target/apache-commons-rdf-javadoc.jar
> > > -rw-rw-r-- 1 stain stain 17618 May 7 17:37
> > > target/apache-commons-rdf-sources.jar
> > > -rw-rw-r-- 1 stain stain 8438 May 7 17:37
> > > target/apache-commons-rdf-test-sources.jar
> > >
> > > They should be called
> > > commons-rdf-simple-0.1.0-incubating.jar
> > > and not
> > > apache-commons-rdf.jar
> > >
> > > -- but somehow now every module produces the same filename in their
> > > corresponding target/ -- I don't think this breaks anything (they are
> > > luckily still mvn installed with correct names) -- just a bit weird
> > > and confusing for non-Maven folks who might want to pick up the
> > > compiled *.jar from target/
> > >
> > > No blocker for this release, but definitely something to sort out.
> > >
> > >
> > >
> > > Have a nice weekend!
> > >
> > >
> > > On 7 May 2015 at 15:27, Sergio Fernández <wi...@apache.org> wrote:
> > >> Hello
> > >>
> > >> I am pleased to be calling this vote for the source release of Apache
> > >> Commons RDF 0.1.0-incubating, composed by:
> > >>
> > >> * commons-rdf-api 0.1.0-incubating
> > >> * commons-rdf-simple 0.1.0-incubating
> > >>
> > >> A candidate for the Commons RDF 0.1.0-incubating release is available
> > at:
> > >>
> > >>
> >
> https://dist.apache.org/repos/dist/dev/incubator/commonsrdf/0.1.0-incubating/
> > >>
> > >> The release candidate is based on the sources from commit
> > >> 454ebc1ff457bcdb34f4671565bc984e6fbbcb77, tagged as 0.1.0-incubating,
> > at:
> > >>
> > >> https://git-wip-us.apache.org/repos/asf/incubator-commonsrdf.git
> > >>
> > >> Release artifacts are signed with the keys available at:
> > >>
> > >> https://dist.apache.org/repos/dist/release/incubator/commonsrdf/KEYS
> > >>
> > >> A staged Maven repository is available for review at:
> > >>
> > >>
> > https://repository.apache.org/content/repositories/orgapachecommons-1095
> > >>
> > >> The changelog for this version is available from JIRA:
> > >>
> > >>
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316620&version=12332056
> > >>
> > >> Please vote on releasing this package as Apache Commons RDF
> > >> 0.1.0-incubating. The vote is open for at least 72 hours and passes
> if a
> > >> majority of at least three +1 IPMC votes are cast.
> > >>
> > >> [ ] +1 Release this package
> > >> [ ] 0 I don't feel strongly about it, but I'm okay with the release
> > >> [ ] -1 Do not release this package because...
> > >>
> > >>
> > >> --
> > >> Sergio Fernández
> > >> Partner Technology Manager
> > >> Redlink GmbH
> > >> m: +43 6602747925
> > >> e: sergio.fernandez@redlink.co
> > >> w: http://redlink.co
> > >
> > >
> > >
> > > --
> > > Stian Soiland-Reyes
> > > Apache Taverna (incubating), Apache Commons RDF (incubating)
> > > http://orcid.org/0000-0001-9842-9718
> >
> >
> >
> > --
> > Stian Soiland-Reyes
> > Apache Taverna (incubating), Apache Commons RDF (incubating)
> > http://orcid.org/0000-0001-9842-9718
> >
>
Re: [VOTE] Release Apache Commons RDF 0.1.0-incubating RC2
Posted by "John D. Ament" <jo...@apache.org>.
If we can include that in the release, it'll save us some concerns on the
general list vote.
John
On Thu, May 7, 2015 at 12:56 PM Stian Soiland-Reyes <st...@apache.org>
wrote:
> I committed fixed LICENSE (s) retrieved from
> https://www.apache.org/licenses/LICENSE-2.0.txt which changed some
> other formatting -- which I don't think is a legal issue or blocker
> for this release.
>
>
> https://github.com/apache/incubator-commonsrdf/commit/90b85287a67d3b64ecc83469de5dbbd1fdf7dce2
>
>
> Inclusion of src/site/resources/css indicates you didn't create the
> release from a fresh git check-out, which I would strongly recommend
> for the future. Starting with an empty ~/.m2/repository is also good
> practice.
>
>
> Thanks for preparing the release candidate!
>
> On 7 May 2015 at 17:49, Stian Soiland-Reyes <st...@apache.org> wrote:
> > +1 (PPMC binding, IPMC non-binding)
> >
> >
> > * Verified signatures from KEYS
> > * Verified sha1/md5 (perhaps these should also be included in email?)
> > fd70a39de363c669744393c57b2fb8f90b15d3c1
> > d245c016612632964b070829aa5079c9ed8d2e9b
> > * zip and tar.gz content match 100%
> > * zip/tar.gz content matches git tag
> > 454ebc1ff457bcdb34f4671565bc984e6fbbcb77 - except:
> > + examples/ missing from archive -- OK for now - but why not include
> it?
> > + empty folder src/site/resources/css in zip -- not quite OK, but
> > I'll let it pass as it is empty
> > * builds with mvn clean install
> > * mvn apache-rat:check passes
> > * No binaries (except png and xcf)
> > * Includes NOTICE and LICENSE -- however the first line of LICENSE
> > looks a bit odd as some whitespace seems removed. Fix for next
> > version.
> > * META-INF/NOTICE and META-INF/LICENSE correctly included in *.jar
> artifacts
> > * Dependencies have acceptable licenses, and do not need to be listed
> > in NOTICE. Checked with mvn license:aggregate-add-third-party (see
> > below)
> >
> >
> > I've thrown in a bit of extra checks for good measures :)
> >
> > * Runs with the modified examples/pom.xml (had to be checked out from
> git)
> > * Staged repository works with the examples/ with a blank .m2/repository/
> > * Filenames of api and simple *.jar from Maven staging repositories
> > matches what gets compiled in */target (I didn't compare beyond
> > filenames)
> >
> >
> >
> >
> > Licenses:
> >
> > Lists of 3 third-party dependencies.
> > (Eclipse Public License 1.0) JUnit (junit:junit:4.12 -
> http://junit.org)
> > (The Apache Software License, Version 2.0) Commons RDF: API
> > (org.apache.commons:commons-rdf-api:0.1.0-incubating -
> > http://commonsrdf.incubator.apache.org/commons-rdf-api)
> > (New BSD License) Hamcrest Core (org.hamcrest:hamcrest-core:1.3 -
> > https://github.com/hamcrest/JavaHamcrest/hamcrest-core)
> >
> >
> >
> > build tested on On Ubuntu 15.04 x64 with:
> >
> > stain@biggie-utopic:/tmp/92/
> dist.apache.org/repos/dist/dev/incubator/commonsrdf/0.1.0-incubating/1/apache-commons-rdf-0.1.0-incubating$
> > mvn -v
> > Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar
> > Apache Maven 3.3.1 (cab6659f9874fa96462afef40fcf6bc033d58c1c;
> > 2015-03-13T20:10:27+00:00)
> > Maven home: /home/stain/software/maven
> > Java version: 1.8.0_45-internal, 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: "3.19.0-15-generic", arch: "amd64", family:
> "unix"
> >
> >
> >
> >
> >
> >
> > Here's another strange thing that is probably also called by settings
> > in the parent pom:
> >
> >
> >
> >
> > stain@biggie-utopic:/tmp/92/
> dist.apache.org/repos/dist/dev/incubator/commonsrdf/0.1.0-incubating/2/apache-commons-rdf-0.1.0-incubating/simple$
> > ls -al target/*jar
> > -rw-rw-r-- 1 stain stain 18873 May 7 17:37 target/apache-commons-rdf.jar
> > -rw-rw-r-- 1 stain stain 35337 May 7 17:37
> > target/apache-commons-rdf-javadoc.jar
> > -rw-rw-r-- 1 stain stain 17618 May 7 17:37
> > target/apache-commons-rdf-sources.jar
> > -rw-rw-r-- 1 stain stain 8438 May 7 17:37
> > target/apache-commons-rdf-test-sources.jar
> >
> > They should be called
> > commons-rdf-simple-0.1.0-incubating.jar
> > and not
> > apache-commons-rdf.jar
> >
> > -- but somehow now every module produces the same filename in their
> > corresponding target/ -- I don't think this breaks anything (they are
> > luckily still mvn installed with correct names) -- just a bit weird
> > and confusing for non-Maven folks who might want to pick up the
> > compiled *.jar from target/
> >
> > No blocker for this release, but definitely something to sort out.
> >
> >
> >
> > Have a nice weekend!
> >
> >
> > On 7 May 2015 at 15:27, Sergio Fernández <wi...@apache.org> wrote:
> >> Hello
> >>
> >> I am pleased to be calling this vote for the source release of Apache
> >> Commons RDF 0.1.0-incubating, composed by:
> >>
> >> * commons-rdf-api 0.1.0-incubating
> >> * commons-rdf-simple 0.1.0-incubating
> >>
> >> A candidate for the Commons RDF 0.1.0-incubating release is available
> at:
> >>
> >>
> https://dist.apache.org/repos/dist/dev/incubator/commonsrdf/0.1.0-incubating/
> >>
> >> The release candidate is based on the sources from commit
> >> 454ebc1ff457bcdb34f4671565bc984e6fbbcb77, tagged as 0.1.0-incubating,
> at:
> >>
> >> https://git-wip-us.apache.org/repos/asf/incubator-commonsrdf.git
> >>
> >> Release artifacts are signed with the keys available at:
> >>
> >> https://dist.apache.org/repos/dist/release/incubator/commonsrdf/KEYS
> >>
> >> A staged Maven repository is available for review at:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1095
> >>
> >> The changelog for this version is available from JIRA:
> >>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316620&version=12332056
> >>
> >> Please vote on releasing this package as Apache Commons RDF
> >> 0.1.0-incubating. The vote is open for at least 72 hours and passes if a
> >> majority of at least three +1 IPMC votes are cast.
> >>
> >> [ ] +1 Release this package
> >> [ ] 0 I don't feel strongly about it, but I'm okay with the release
> >> [ ] -1 Do not release this package because...
> >>
> >>
> >> --
> >> Sergio Fernández
> >> Partner Technology Manager
> >> Redlink GmbH
> >> m: +43 6602747925
> >> e: sergio.fernandez@redlink.co
> >> w: http://redlink.co
> >
> >
> >
> > --
> > Stian Soiland-Reyes
> > Apache Taverna (incubating), Apache Commons RDF (incubating)
> > http://orcid.org/0000-0001-9842-9718
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/0000-0001-9842-9718
>
Re: [VOTE] Release Apache Commons RDF 0.1.0-incubating RC2
Posted by Stian Soiland-Reyes <st...@apache.org>.
I committed fixed LICENSE (s) retrieved from
https://www.apache.org/licenses/LICENSE-2.0.txt which changed some
other formatting -- which I don't think is a legal issue or blocker
for this release.
https://github.com/apache/incubator-commonsrdf/commit/90b85287a67d3b64ecc83469de5dbbd1fdf7dce2
Inclusion of src/site/resources/css indicates you didn't create the
release from a fresh git check-out, which I would strongly recommend
for the future. Starting with an empty ~/.m2/repository is also good
practice.
Thanks for preparing the release candidate!
On 7 May 2015 at 17:49, Stian Soiland-Reyes <st...@apache.org> wrote:
> +1 (PPMC binding, IPMC non-binding)
>
>
> * Verified signatures from KEYS
> * Verified sha1/md5 (perhaps these should also be included in email?)
> fd70a39de363c669744393c57b2fb8f90b15d3c1
> d245c016612632964b070829aa5079c9ed8d2e9b
> * zip and tar.gz content match 100%
> * zip/tar.gz content matches git tag
> 454ebc1ff457bcdb34f4671565bc984e6fbbcb77 - except:
> + examples/ missing from archive -- OK for now - but why not include it?
> + empty folder src/site/resources/css in zip -- not quite OK, but
> I'll let it pass as it is empty
> * builds with mvn clean install
> * mvn apache-rat:check passes
> * No binaries (except png and xcf)
> * Includes NOTICE and LICENSE -- however the first line of LICENSE
> looks a bit odd as some whitespace seems removed. Fix for next
> version.
> * META-INF/NOTICE and META-INF/LICENSE correctly included in *.jar artifacts
> * Dependencies have acceptable licenses, and do not need to be listed
> in NOTICE. Checked with mvn license:aggregate-add-third-party (see
> below)
>
>
> I've thrown in a bit of extra checks for good measures :)
>
> * Runs with the modified examples/pom.xml (had to be checked out from git)
> * Staged repository works with the examples/ with a blank .m2/repository/
> * Filenames of api and simple *.jar from Maven staging repositories
> matches what gets compiled in */target (I didn't compare beyond
> filenames)
>
>
>
>
> Licenses:
>
> Lists of 3 third-party dependencies.
> (Eclipse Public License 1.0) JUnit (junit:junit:4.12 - http://junit.org)
> (The Apache Software License, Version 2.0) Commons RDF: API
> (org.apache.commons:commons-rdf-api:0.1.0-incubating -
> http://commonsrdf.incubator.apache.org/commons-rdf-api)
> (New BSD License) Hamcrest Core (org.hamcrest:hamcrest-core:1.3 -
> https://github.com/hamcrest/JavaHamcrest/hamcrest-core)
>
>
>
> build tested on On Ubuntu 15.04 x64 with:
>
> stain@biggie-utopic:/tmp/92/dist.apache.org/repos/dist/dev/incubator/commonsrdf/0.1.0-incubating/1/apache-commons-rdf-0.1.0-incubating$
> mvn -v
> Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar
> Apache Maven 3.3.1 (cab6659f9874fa96462afef40fcf6bc033d58c1c;
> 2015-03-13T20:10:27+00:00)
> Maven home: /home/stain/software/maven
> Java version: 1.8.0_45-internal, 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: "3.19.0-15-generic", arch: "amd64", family: "unix"
>
>
>
>
>
>
> Here's another strange thing that is probably also called by settings
> in the parent pom:
>
>
>
>
> stain@biggie-utopic:/tmp/92/dist.apache.org/repos/dist/dev/incubator/commonsrdf/0.1.0-incubating/2/apache-commons-rdf-0.1.0-incubating/simple$
> ls -al target/*jar
> -rw-rw-r-- 1 stain stain 18873 May 7 17:37 target/apache-commons-rdf.jar
> -rw-rw-r-- 1 stain stain 35337 May 7 17:37
> target/apache-commons-rdf-javadoc.jar
> -rw-rw-r-- 1 stain stain 17618 May 7 17:37
> target/apache-commons-rdf-sources.jar
> -rw-rw-r-- 1 stain stain 8438 May 7 17:37
> target/apache-commons-rdf-test-sources.jar
>
> They should be called
> commons-rdf-simple-0.1.0-incubating.jar
> and not
> apache-commons-rdf.jar
>
> -- but somehow now every module produces the same filename in their
> corresponding target/ -- I don't think this breaks anything (they are
> luckily still mvn installed with correct names) -- just a bit weird
> and confusing for non-Maven folks who might want to pick up the
> compiled *.jar from target/
>
> No blocker for this release, but definitely something to sort out.
>
>
>
> Have a nice weekend!
>
>
> On 7 May 2015 at 15:27, Sergio Fernández <wi...@apache.org> wrote:
>> Hello
>>
>> I am pleased to be calling this vote for the source release of Apache
>> Commons RDF 0.1.0-incubating, composed by:
>>
>> * commons-rdf-api 0.1.0-incubating
>> * commons-rdf-simple 0.1.0-incubating
>>
>> A candidate for the Commons RDF 0.1.0-incubating release is available at:
>>
>> https://dist.apache.org/repos/dist/dev/incubator/commonsrdf/0.1.0-incubating/
>>
>> The release candidate is based on the sources from commit
>> 454ebc1ff457bcdb34f4671565bc984e6fbbcb77, tagged as 0.1.0-incubating, at:
>>
>> https://git-wip-us.apache.org/repos/asf/incubator-commonsrdf.git
>>
>> Release artifacts are signed with the keys available at:
>>
>> https://dist.apache.org/repos/dist/release/incubator/commonsrdf/KEYS
>>
>> A staged Maven repository is available for review at:
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1095
>>
>> The changelog for this version is available from JIRA:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316620&version=12332056
>>
>> Please vote on releasing this package as Apache Commons RDF
>> 0.1.0-incubating. The vote is open for at least 72 hours and passes if a
>> majority of at least three +1 IPMC votes are cast.
>>
>> [ ] +1 Release this package
>> [ ] 0 I don't feel strongly about it, but I'm okay with the release
>> [ ] -1 Do not release this package because...
>>
>>
>> --
>> Sergio Fernández
>> Partner Technology Manager
>> Redlink GmbH
>> m: +43 6602747925
>> e: sergio.fernandez@redlink.co
>> w: http://redlink.co
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/0000-0001-9842-9718
--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718
Re: [VOTE] Release Apache Commons RDF 0.1.0-incubating RC2
Posted by Stian Soiland-Reyes <st...@apache.org>.
+1 (PPMC binding, IPMC non-binding)
* Verified signatures from KEYS
* Verified sha1/md5 (perhaps these should also be included in email?)
fd70a39de363c669744393c57b2fb8f90b15d3c1
d245c016612632964b070829aa5079c9ed8d2e9b
* zip and tar.gz content match 100%
* zip/tar.gz content matches git tag
454ebc1ff457bcdb34f4671565bc984e6fbbcb77 - except:
+ examples/ missing from archive -- OK for now - but why not include it?
+ empty folder src/site/resources/css in zip -- not quite OK, but
I'll let it pass as it is empty
* builds with mvn clean install
* mvn apache-rat:check passes
* No binaries (except png and xcf)
* Includes NOTICE and LICENSE -- however the first line of LICENSE
looks a bit odd as some whitespace seems removed. Fix for next
version.
* META-INF/NOTICE and META-INF/LICENSE correctly included in *.jar artifacts
* Dependencies have acceptable licenses, and do not need to be listed
in NOTICE. Checked with mvn license:aggregate-add-third-party (see
below)
I've thrown in a bit of extra checks for good measures :)
* Runs with the modified examples/pom.xml (had to be checked out from git)
* Staged repository works with the examples/ with a blank .m2/repository/
* Filenames of api and simple *.jar from Maven staging repositories
matches what gets compiled in */target (I didn't compare beyond
filenames)
Licenses:
Lists of 3 third-party dependencies.
(Eclipse Public License 1.0) JUnit (junit:junit:4.12 - http://junit.org)
(The Apache Software License, Version 2.0) Commons RDF: API
(org.apache.commons:commons-rdf-api:0.1.0-incubating -
http://commonsrdf.incubator.apache.org/commons-rdf-api)
(New BSD License) Hamcrest Core (org.hamcrest:hamcrest-core:1.3 -
https://github.com/hamcrest/JavaHamcrest/hamcrest-core)
build tested on On Ubuntu 15.04 x64 with:
stain@biggie-utopic:/tmp/92/dist.apache.org/repos/dist/dev/incubator/commonsrdf/0.1.0-incubating/1/apache-commons-rdf-0.1.0-incubating$
mvn -v
Picked up JAVA_TOOL_OPTIONS: -javaagent:/usr/share/java/jayatanaag.jar
Apache Maven 3.3.1 (cab6659f9874fa96462afef40fcf6bc033d58c1c;
2015-03-13T20:10:27+00:00)
Maven home: /home/stain/software/maven
Java version: 1.8.0_45-internal, 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: "3.19.0-15-generic", arch: "amd64", family: "unix"
Here's another strange thing that is probably also called by settings
in the parent pom:
stain@biggie-utopic:/tmp/92/dist.apache.org/repos/dist/dev/incubator/commonsrdf/0.1.0-incubating/2/apache-commons-rdf-0.1.0-incubating/simple$
ls -al target/*jar
-rw-rw-r-- 1 stain stain 18873 May 7 17:37 target/apache-commons-rdf.jar
-rw-rw-r-- 1 stain stain 35337 May 7 17:37
target/apache-commons-rdf-javadoc.jar
-rw-rw-r-- 1 stain stain 17618 May 7 17:37
target/apache-commons-rdf-sources.jar
-rw-rw-r-- 1 stain stain 8438 May 7 17:37
target/apache-commons-rdf-test-sources.jar
They should be called
commons-rdf-simple-0.1.0-incubating.jar
and not
apache-commons-rdf.jar
-- but somehow now every module produces the same filename in their
corresponding target/ -- I don't think this breaks anything (they are
luckily still mvn installed with correct names) -- just a bit weird
and confusing for non-Maven folks who might want to pick up the
compiled *.jar from target/
No blocker for this release, but definitely something to sort out.
Have a nice weekend!
On 7 May 2015 at 15:27, Sergio Fernández <wi...@apache.org> wrote:
> Hello
>
> I am pleased to be calling this vote for the source release of Apache
> Commons RDF 0.1.0-incubating, composed by:
>
> * commons-rdf-api 0.1.0-incubating
> * commons-rdf-simple 0.1.0-incubating
>
> A candidate for the Commons RDF 0.1.0-incubating release is available at:
>
> https://dist.apache.org/repos/dist/dev/incubator/commonsrdf/0.1.0-incubating/
>
> The release candidate is based on the sources from commit
> 454ebc1ff457bcdb34f4671565bc984e6fbbcb77, tagged as 0.1.0-incubating, at:
>
> https://git-wip-us.apache.org/repos/asf/incubator-commonsrdf.git
>
> Release artifacts are signed with the keys available at:
>
> https://dist.apache.org/repos/dist/release/incubator/commonsrdf/KEYS
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1095
>
> The changelog for this version is available from JIRA:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316620&version=12332056
>
> Please vote on releasing this package as Apache Commons RDF
> 0.1.0-incubating. The vote is open for at least 72 hours and passes if a
> majority of at least three +1 IPMC votes are cast.
>
> [ ] +1 Release this package
> [ ] 0 I don't feel strongly about it, but I'm okay with the release
> [ ] -1 Do not release this package because...
>
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 6602747925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co
--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718
Re: [VOTE] Release Apache Commons RDF 0.1.0-incubating RC2
Posted by Sergio Fernández <wi...@apache.org>.
On Thu, May 7, 2015 at 10:29 PM, Andy Seaborne <an...@apache.org> wrote:
>
> Notes:
>
> As Stain notes - the target jars have the same name.
> Proposed repo is OK (presumably because all uploads are forced to have the
> artifact name and we don't have any destination overlaps).
>
> Suggestion:
> Only produce the zip version so there is exactly one "source release" file
> and so only one to check.
If we want only a zip tarball, it's easy. Because I guess that's
consequence of 'fighting' with the commons-parent and the
maven-assembly-plugin. I have an idea how to solve, I'll implement it
during the weekend, so will be ready for next releases.
--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernandez@redlink.co
w: http://redlink.co
Re: [VOTE] Release Apache Commons RDF 0.1.0-incubating RC2
Posted by Benedikt Ritter <br...@apache.org>.
Hello Andy,
2015-05-11 23:43 GMT+02:00 Andy Seaborne <an...@apache.org>:
> On 11/05/15 19:12, John D. Ament wrote:
>
>> Since they're incubating, Commons RDF would upload to incubator/dist
>> instead, but generally yes all the same would apply.
>>
>> On Mon, May 11, 2015 at 2:08 PM Benedikt Ritter <br...@apache.org>
>> wrote:
>>
>> 2015-05-08 14:45 GMT+02:00 Stian Soiland-Reyes <st...@apache.org>:
>>>
>>> On 7 May 2015 at 21:29, Andy Seaborne <an...@apache.org> wrote:
>>>>
>>>>> Suggestion:
>>>>> Only produce the zip version so there is exactly one "source release"
>>>>>
>>>> file
>>>>
>>>>> and so only one to check.
>>>>>
>>>>
>>>> I think it's good to have both for longevity, and for the benefit of
>>>> OS distributions and automated builds, zip is after all a confusingly
>>>> defined format, and it is just a diff -ur to check their content is
>>>> the same.
>>>>
>>>> It's not like we will have a very large download page :)
>>>>
>>>> (btw - could someone draft that? How is that done in Commons way? I
>>>> remember something to watch out for is chmod +x on the cgi-bin..)
>>>>
>>>>
>>> Sorry, I had to take care of that Commons CLI release the Groovy project
>>> requested. I'm trying to follow up this discussion now...
>>>
>>> Commons projects usually produce:
>>> - tar.gz and zip archives of the sources and binaries (uploaded to
>>>
>>
> What's the difference with the "source-release" that the Apache parent
> org.apache.apache enabled with, enabled with -Papache-release?
>
TBH I don't know why commons has it's own release profile. I've never
worked for an other project so I didn't know about -Papache-release from
apache-parent until now.
>
> <!-- Create a source-release artifact that contains the fully buildable
> project directory source structure. This is the artifact which is
> the official subject of any release vote.
> -->
>
> and the "src" files made in commons-parent?
>
> Do commons components not use -Papache-release?
>
No we use -Prelease as described in [1].
Benedikt
[1] http://commons.apache.org/releases/prepare.html
>
> Andy
>
> https://dist.apache.org/repos/dist/release/commons/)
>>> - maven artifacts for maven central (before closing into the staging
>>> repo,
>>> we remove the tar.gz and zips from the staging repo so that only jars and
>>> poms are pushed to maven central)
>>>
>>> I think Commons RDF should do the same. What was the reason for dropping
>>> the tar.gz src build? Has there been a problem with Commons parent?
>>>
>>
> 3 source bundles to check.
>
>
>
>>> br,
>>> Benedikt
>>>
>>>
>>>
>>>>
>>>> What I wondered is why the proposed source distributions in
>>>> dist.apache.org are not simply byte-wise equal to the -src in
>>>>
>>>>
>>>>
>>> https://repository.apache.org/content/repositories/orgapachecommons-1095/org/apache/commons/commons-rdf-parent/0.1.0-incubating/
>>>
>>>> ?
>>>>
>>>> (and why does that folder contain bout -src and -source-release.zip?)
>>>>
>>>> (Don't worry, the files inside it are byte-equal to the ones in the
>>>> proposed release archives - except that -source.zip also contains the
>>>> harmless examples/ folder)
>>>>
>>>>
>>>>
>>>> --
>>>> Stian Soiland-Reyes
>>>> Apache Taverna (incubating), Apache Commons RDF (incubating)
>>>> http://orcid.org/0000-0001-9842-9718
>>>>
>>>>
>>>
>>>
>>> --
>>> http://people.apache.org/~britter/
>>> http://www.systemoutprintln.de/
>>> http://twitter.com/BenediktRitter
>>> http://github.com/britter
>>>
>>>
>>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [VOTE] Release Apache Commons RDF 0.1.0-incubating RC2
Posted by Andy Seaborne <an...@apache.org>.
On 11/05/15 19:12, John D. Ament wrote:
> Since they're incubating, Commons RDF would upload to incubator/dist
> instead, but generally yes all the same would apply.
>
> On Mon, May 11, 2015 at 2:08 PM Benedikt Ritter <br...@apache.org> wrote:
>
>> 2015-05-08 14:45 GMT+02:00 Stian Soiland-Reyes <st...@apache.org>:
>>
>>> On 7 May 2015 at 21:29, Andy Seaborne <an...@apache.org> wrote:
>>>> Suggestion:
>>>> Only produce the zip version so there is exactly one "source release"
>>> file
>>>> and so only one to check.
>>>
>>> I think it's good to have both for longevity, and for the benefit of
>>> OS distributions and automated builds, zip is after all a confusingly
>>> defined format, and it is just a diff -ur to check their content is
>>> the same.
>>>
>>> It's not like we will have a very large download page :)
>>>
>>> (btw - could someone draft that? How is that done in Commons way? I
>>> remember something to watch out for is chmod +x on the cgi-bin..)
>>>
>>
>> Sorry, I had to take care of that Commons CLI release the Groovy project
>> requested. I'm trying to follow up this discussion now...
>>
>> Commons projects usually produce:
>> - tar.gz and zip archives of the sources and binaries (uploaded to
What's the difference with the "source-release" that the Apache parent
org.apache.apache enabled with, enabled with -Papache-release?
<!-- Create a source-release artifact that contains the fully buildable
project directory source structure. This is the artifact which is
the official subject of any release vote.
-->
and the "src" files made in commons-parent?
Do commons components not use -Papache-release?
Andy
>> https://dist.apache.org/repos/dist/release/commons/)
>> - maven artifacts for maven central (before closing into the staging repo,
>> we remove the tar.gz and zips from the staging repo so that only jars and
>> poms are pushed to maven central)
>>
>> I think Commons RDF should do the same. What was the reason for dropping
>> the tar.gz src build? Has there been a problem with Commons parent?
3 source bundles to check.
>>
>> br,
>> Benedikt
>>
>>
>>>
>>>
>>> What I wondered is why the proposed source distributions in
>>> dist.apache.org are not simply byte-wise equal to the -src in
>>>
>>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1095/org/apache/commons/commons-rdf-parent/0.1.0-incubating/
>>> ?
>>>
>>> (and why does that folder contain bout -src and -source-release.zip?)
>>>
>>> (Don't worry, the files inside it are byte-equal to the ones in the
>>> proposed release archives - except that -source.zip also contains the
>>> harmless examples/ folder)
>>>
>>>
>>>
>>> --
>>> Stian Soiland-Reyes
>>> Apache Taverna (incubating), Apache Commons RDF (incubating)
>>> http://orcid.org/0000-0001-9842-9718
>>>
>>
>>
>>
>> --
>> http://people.apache.org/~britter/
>> http://www.systemoutprintln.de/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>>
>
Re: [VOTE] Release Apache Commons RDF 0.1.0-incubating RC2
Posted by "John D. Ament" <jo...@apache.org>.
Since they're incubating, Commons RDF would upload to incubator/dist
instead, but generally yes all the same would apply.
On Mon, May 11, 2015 at 2:08 PM Benedikt Ritter <br...@apache.org> wrote:
> 2015-05-08 14:45 GMT+02:00 Stian Soiland-Reyes <st...@apache.org>:
>
> > On 7 May 2015 at 21:29, Andy Seaborne <an...@apache.org> wrote:
> > > Suggestion:
> > > Only produce the zip version so there is exactly one "source release"
> > file
> > > and so only one to check.
> >
> > I think it's good to have both for longevity, and for the benefit of
> > OS distributions and automated builds, zip is after all a confusingly
> > defined format, and it is just a diff -ur to check their content is
> > the same.
> >
> > It's not like we will have a very large download page :)
> >
> > (btw - could someone draft that? How is that done in Commons way? I
> > remember something to watch out for is chmod +x on the cgi-bin..)
> >
>
> Sorry, I had to take care of that Commons CLI release the Groovy project
> requested. I'm trying to follow up this discussion now...
>
> Commons projects usually produce:
> - tar.gz and zip archives of the sources and binaries (uploaded to
> https://dist.apache.org/repos/dist/release/commons/)
> - maven artifacts for maven central (before closing into the staging repo,
> we remove the tar.gz and zips from the staging repo so that only jars and
> poms are pushed to maven central)
>
> I think Commons RDF should do the same. What was the reason for dropping
> the tar.gz src build? Has there been a problem with Commons parent?
>
> br,
> Benedikt
>
>
> >
> >
> > What I wondered is why the proposed source distributions in
> > dist.apache.org are not simply byte-wise equal to the -src in
> >
> >
> https://repository.apache.org/content/repositories/orgapachecommons-1095/org/apache/commons/commons-rdf-parent/0.1.0-incubating/
> > ?
> >
> > (and why does that folder contain bout -src and -source-release.zip?)
> >
> > (Don't worry, the files inside it are byte-equal to the ones in the
> > proposed release archives - except that -source.zip also contains the
> > harmless examples/ folder)
> >
> >
> >
> > --
> > Stian Soiland-Reyes
> > Apache Taverna (incubating), Apache Commons RDF (incubating)
> > http://orcid.org/0000-0001-9842-9718
> >
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
Re: [VOTE] Release Apache Commons RDF 0.1.0-incubating RC2
Posted by Benedikt Ritter <br...@apache.org>.
2015-05-08 14:45 GMT+02:00 Stian Soiland-Reyes <st...@apache.org>:
> On 7 May 2015 at 21:29, Andy Seaborne <an...@apache.org> wrote:
> > Suggestion:
> > Only produce the zip version so there is exactly one "source release"
> file
> > and so only one to check.
>
> I think it's good to have both for longevity, and for the benefit of
> OS distributions and automated builds, zip is after all a confusingly
> defined format, and it is just a diff -ur to check their content is
> the same.
>
> It's not like we will have a very large download page :)
>
> (btw - could someone draft that? How is that done in Commons way? I
> remember something to watch out for is chmod +x on the cgi-bin..)
>
Sorry, I had to take care of that Commons CLI release the Groovy project
requested. I'm trying to follow up this discussion now...
Commons projects usually produce:
- tar.gz and zip archives of the sources and binaries (uploaded to
https://dist.apache.org/repos/dist/release/commons/)
- maven artifacts for maven central (before closing into the staging repo,
we remove the tar.gz and zips from the staging repo so that only jars and
poms are pushed to maven central)
I think Commons RDF should do the same. What was the reason for dropping
the tar.gz src build? Has there been a problem with Commons parent?
br,
Benedikt
>
>
> What I wondered is why the proposed source distributions in
> dist.apache.org are not simply byte-wise equal to the -src in
>
> https://repository.apache.org/content/repositories/orgapachecommons-1095/org/apache/commons/commons-rdf-parent/0.1.0-incubating/
> ?
>
> (and why does that folder contain bout -src and -source-release.zip?)
>
> (Don't worry, the files inside it are byte-equal to the ones in the
> proposed release archives - except that -source.zip also contains the
> harmless examples/ folder)
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/0000-0001-9842-9718
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [VOTE] Release Apache Commons RDF 0.1.0-incubating RC2
Posted by Benedikt Ritter <br...@apache.org>.
2015-05-12 13:25 GMT+02:00 Stian Soiland-Reyes <st...@apache.org>:
> On 9 May 2015 at 18:21, Andy Seaborne <an...@apache.org> wrote:
> >>> But the source release isn't in an OS distribution or automated builds.
> >>> It's a one-time gold copy.
> > so I'm confused as to what you think the source-release ('src') is for.
> > and why do you think automated builds are working (repeatedly) off the
> > source release code tree?
>
> With automated build, I meant by anyone using it downstream who for
> arbitrary reasons don't want to use the Maven binaries. A good example
> is Debian who will store the latest release tar-ball and then build
> this in their automated build infrastructure.
>
> > Repacking for a linux distro is to build once.
>
> No, distributions build again for each distribution version (at
> least). This is done on automatic build systems.
>
> Example:
>
> https://packages.debian.org/zh-cn/source/sid/commons-math
> includes
>
> commons-math_2.2.orig.tar.gz
> md5 6261d7991154c992477b32b8f3bea18b
>
> which matches exactly the upstream tar.gz:
>
>
> http://www.apache.org/dist/commons/math/source/commons-math-2.2-src.tar.gz.md5
>
>
> > "users" here are not
> > application writers (they use maven central) but people wanting a gold
> copy
> > to verify, building thier own binaries.
>
> And those would often prefer non-proprietary formats..
>
>
> > Concretely - why isn't a docker build using the maven artifacts? (this
> is a
> > library, not an application).
>
> It could just as well do that, yes. Luckily we have GPG signatures also on
> the
> JARs in Maven Central so they can be checked directly.
>
>
>
> > A scan of /dist/ shows no standard practice but one version (zip or
> tar.gz)
> > is possibly more common that multiple forms. "ant" has three forms.
>
> I think this should be aligned with what is practice within
> Commons projects. Other projects might have different
> potential downstream users, e.g. almost nobody compiles
> OpenOffice :)
>
> If Commons in general have just .zip (or .tar.gz) then I'm perfectly
> fine with that :).
>
> If the practice is unclear, than my vote would be to keep both.
>
We provide both, zips and tar.gz. Have a look at for example
https://dist.apache.org/repos/dist/release/commons/lang/
br,
Benedikt
>
> But I won't block if there is overwhelming support for .zip here.. :)
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/0000-0001-9842-9718
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Re: [VOTE] Release Apache Commons RDF 0.1.0-incubating RC2
Posted by Stian Soiland-Reyes <st...@apache.org>.
On 9 May 2015 at 18:21, Andy Seaborne <an...@apache.org> wrote:
>>> But the source release isn't in an OS distribution or automated builds.
>>> It's a one-time gold copy.
> so I'm confused as to what you think the source-release ('src') is for.
> and why do you think automated builds are working (repeatedly) off the
> source release code tree?
With automated build, I meant by anyone using it downstream who for
arbitrary reasons don't want to use the Maven binaries. A good example
is Debian who will store the latest release tar-ball and then build
this in their automated build infrastructure.
> Repacking for a linux distro is to build once.
No, distributions build again for each distribution version (at
least). This is done on automatic build systems.
Example:
https://packages.debian.org/zh-cn/source/sid/commons-math
includes
commons-math_2.2.orig.tar.gz
md5 6261d7991154c992477b32b8f3bea18b
which matches exactly the upstream tar.gz:
http://www.apache.org/dist/commons/math/source/commons-math-2.2-src.tar.gz.md5
> "users" here are not
> application writers (they use maven central) but people wanting a gold copy
> to verify, building thier own binaries.
And those would often prefer non-proprietary formats..
> Concretely - why isn't a docker build using the maven artifacts? (this is a
> library, not an application).
It could just as well do that, yes. Luckily we have GPG signatures also on the
JARs in Maven Central so they can be checked directly.
> A scan of /dist/ shows no standard practice but one version (zip or tar.gz)
> is possibly more common that multiple forms. "ant" has three forms.
I think this should be aligned with what is practice within
Commons projects. Other projects might have different
potential downstream users, e.g. almost nobody compiles
OpenOffice :)
If Commons in general have just .zip (or .tar.gz) then I'm perfectly
fine with that :).
If the practice is unclear, than my vote would be to keep both.
But I won't block if there is overwhelming support for .zip here.. :)
--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718
Re: [VOTE] Release Apache Commons RDF 0.1.0-incubating RC2
Posted by Andy Seaborne <an...@apache.org>.
On 09/05/15 15:28, Stian Soiland-Reyes wrote:
> So my -0 for a zip-only source release.
>
> How do you know what downstream users will do with our source archive? As
> an Apache Common product we should not place any limits on downstream and
> future usage.
I addressed that with:
>> But the source release isn't in an OS distribution or automated builds.
>> It's a one-time gold copy.
so I'm confused as to what you think the source-release ('src') is for.
and why do you think automated builds are working (repeatedly) off the
source release code tree?
Repacking for a linux distro is to build once. "users" here are not
application writers (they use maven central) but people wanting a gold
copy to verify, building thier own binaries.
> tar.gz is standard UNIX archive, for instance with Docker images it would
> work out of the box, while zip requires apt-get install unzip (or using jar
> x).
Concretely - why isn't a docker build using the maven artifacts? (this
is a library, not an application).
A scan of /dist/ shows no standard practice but one version (zip or
tar.gz) is possibly more common that multiple forms. "ant" has three forms.
> Given that both are built automatically and we really only need one of the
> RC reviewers to verify the file content matches the other (I can contribute
> a script), then it is not a particularly large overhead IMHO.
>
> I am more worried about the multiple confusing -source archives in the
> Maven repo (probably the two Maven parents overlapping)
The Apache parent produces one ("source-release" zip).
It's the commons parent that is creating the two 'src'
We might as well do what it does.
Andy
> and the lack of any
> automated verification of the binaries that go straight into Maven Cental
> - even though they are secondary to the source release these are what will
> appear around the world.
What might we do there?
Isn't that the role of building from source release?
> On 8 May 2015 16:07, "Andy Seaborne" <an...@apache.org> wrote:
>
>> On 08/05/15 13:45, Stian Soiland-Reyes wrote:
>>
>>> On 7 May 2015 at 21:29, Andy Seaborne <an...@apache.org> wrote:
>>>
>>>> Suggestion:
>>>> Only produce the zip version so there is exactly one "source release"
>>>> file
>>>> and so only one to check.
>>>>
>>>
>>> I think it's good to have both for longevity, and for the benefit of
>>> OS distributions and automated builds, zip is after all a confusingly
>>> defined format, and it is just a diff -ur to check their content is
>>> the same.
>>>
>>
>> It is a trade off - if there are two files, they both need checking or
>> some way to guarantee they have the same content.
>>
>> But the source release isn't in an OS distribution or automated builds.
>> It's a one-time gold copy.
>>
>>
>>> It's not like we will have a very large download page :)
>>>
>>> (btw - could someone draft that? How is that done in Commons way? I
>>> remember something to watch out for is chmod +x on the cgi-bin..)
>>>
>>>
>>> What I wondered is why the proposed source distributions in
>>> dist.apache.org are not simply byte-wise equal to the -src in
>>>
>>> https://repository.apache.org/content/repositories/orgapachecommons-1095/org/apache/commons/commons-rdf-parent/0.1.0-incubating/
>>> ?
>>>
>>> (and why does that folder contain bout -src and -source-release.zip?)
>>>
>>> (Don't worry, the files inside it are byte-equal to the ones in the
>>> proposed release archives - except that -source.zip also contains the
>>> harmless examples/ folder)
>>>
>>>
>> Good question.
>>
>> source-release is from the Apache parent.
>>
>>
>>
>
Re: [VOTE] Release Apache Commons RDF 0.1.0-incubating RC2
Posted by Stian Soiland-Reyes <st...@apache.org>.
So my -0 for a zip-only source release.
How do you know what downstream users will do with our source archive? As
an Apache Common product we should not place any limits on downstream and
future usage.
tar.gz is standard UNIX archive, for instance with Docker images it would
work out of the box, while zip requires apt-get install unzip (or using jar
x).
Given that both are built automatically and we really only need one of the
RC reviewers to verify the file content matches the other (I can contribute
a script), then it is not a particularly large overhead IMHO.
I am more worried about the multiple confusing -source archives in the
Maven repo (probably the two Maven parents overlapping) and the lack of any
automated verification of the binaries that go straight into Maven Cental
- even though they are secondary to the source release these are what will
appear around the world.
On 8 May 2015 16:07, "Andy Seaborne" <an...@apache.org> wrote:
> On 08/05/15 13:45, Stian Soiland-Reyes wrote:
>
>> On 7 May 2015 at 21:29, Andy Seaborne <an...@apache.org> wrote:
>>
>>> Suggestion:
>>> Only produce the zip version so there is exactly one "source release"
>>> file
>>> and so only one to check.
>>>
>>
>> I think it's good to have both for longevity, and for the benefit of
>> OS distributions and automated builds, zip is after all a confusingly
>> defined format, and it is just a diff -ur to check their content is
>> the same.
>>
>
> It is a trade off - if there are two files, they both need checking or
> some way to guarantee they have the same content.
>
> But the source release isn't in an OS distribution or automated builds.
> It's a one-time gold copy.
>
>
>> It's not like we will have a very large download page :)
>>
>> (btw - could someone draft that? How is that done in Commons way? I
>> remember something to watch out for is chmod +x on the cgi-bin..)
>>
>>
>> What I wondered is why the proposed source distributions in
>> dist.apache.org are not simply byte-wise equal to the -src in
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1095/org/apache/commons/commons-rdf-parent/0.1.0-incubating/
>> ?
>>
>> (and why does that folder contain bout -src and -source-release.zip?)
>>
>> (Don't worry, the files inside it are byte-equal to the ones in the
>> proposed release archives - except that -source.zip also contains the
>> harmless examples/ folder)
>>
>>
> Good question.
>
> source-release is from the Apache parent.
>
>
>
Re: [VOTE] Release Apache Commons RDF 0.1.0-incubating RC2
Posted by Andy Seaborne <an...@apache.org>.
On 08/05/15 13:45, Stian Soiland-Reyes wrote:
> On 7 May 2015 at 21:29, Andy Seaborne <an...@apache.org> wrote:
>> Suggestion:
>> Only produce the zip version so there is exactly one "source release" file
>> and so only one to check.
>
> I think it's good to have both for longevity, and for the benefit of
> OS distributions and automated builds, zip is after all a confusingly
> defined format, and it is just a diff -ur to check their content is
> the same.
It is a trade off - if there are two files, they both need checking or
some way to guarantee they have the same content.
But the source release isn't in an OS distribution or automated builds.
It's a one-time gold copy.
>
> It's not like we will have a very large download page :)
>
> (btw - could someone draft that? How is that done in Commons way? I
> remember something to watch out for is chmod +x on the cgi-bin..)
>
>
> What I wondered is why the proposed source distributions in
> dist.apache.org are not simply byte-wise equal to the -src in
> https://repository.apache.org/content/repositories/orgapachecommons-1095/org/apache/commons/commons-rdf-parent/0.1.0-incubating/
> ?
>
> (and why does that folder contain bout -src and -source-release.zip?)
>
> (Don't worry, the files inside it are byte-equal to the ones in the
> proposed release archives - except that -source.zip also contains the
> harmless examples/ folder)
>
Good question.
source-release is from the Apache parent.
Re: [VOTE] Release Apache Commons RDF 0.1.0-incubating RC2
Posted by Stian Soiland-Reyes <st...@apache.org>.
On 7 May 2015 at 21:29, Andy Seaborne <an...@apache.org> wrote:
> Suggestion:
> Only produce the zip version so there is exactly one "source release" file
> and so only one to check.
I think it's good to have both for longevity, and for the benefit of
OS distributions and automated builds, zip is after all a confusingly
defined format, and it is just a diff -ur to check their content is
the same.
It's not like we will have a very large download page :)
(btw - could someone draft that? How is that done in Commons way? I
remember something to watch out for is chmod +x on the cgi-bin..)
What I wondered is why the proposed source distributions in
dist.apache.org are not simply byte-wise equal to the -src in
https://repository.apache.org/content/repositories/orgapachecommons-1095/org/apache/commons/commons-rdf-parent/0.1.0-incubating/
?
(and why does that folder contain bout -src and -source-release.zip?)
(Don't worry, the files inside it are byte-equal to the ones in the
proposed release archives - except that -source.zip also contains the
harmless examples/ folder)
--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718
Re: [VOTE] Release Apache Commons RDF 0.1.0-incubating RC2
Posted by Andy Seaborne <an...@apache.org>.
+1 : release (IPMC binding)
On 07/05/15 15:27, Sergio Fernández wrote:
> Hello
>
> I am pleased to be calling this vote for the source release of Apache
> Commons RDF 0.1.0-incubating, composed by:
>
> * commons-rdf-api 0.1.0-incubating
> * commons-rdf-simple 0.1.0-incubating
>
> A candidate for the Commons RDF 0.1.0-incubating release is available at:
>
> https://dist.apache.org/repos/dist/dev/incubator/commonsrdf/0.1.0-incubating/
>
> The release candidate is based on the sources from commit
> 454ebc1ff457bcdb34f4671565bc984e6fbbcb77, tagged as 0.1.0-incubating, at:
>
> https://git-wip-us.apache.org/repos/asf/incubator-commonsrdf.git
>
> Release artifacts are signed with the keys available at:
>
> https://dist.apache.org/repos/dist/release/incubator/commonsrdf/KEYS
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1095
>
> The changelog for this version is available from JIRA:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316620&version=12332056
>
> Please vote on releasing this package as Apache Commons RDF
> 0.1.0-incubating. The vote is open for at least 72 hours and passes if a
> majority of at least three +1 IPMC votes are cast.
>
> [ ] +1 Release this package
> [ ] 0 I don't feel strongly about it, but I'm okay with the release
> [ ] -1 Do not release this package because...
Check steps:
+ check signatures and checksums
Yes
+ check LICENSE and NOTICE
source-release: yes
repo artifacts: yes
+ build from source release zip or tar.gz
Yes - "mvn clean test" of tar.gz
+ check LICENSE and NOTICE in artifacts
Yes
+ check the dependencies.
OK
+ do all the tests work?
Yes
+ fetch from git, does it contain reproduceable sources?
Yes
Notes:
As Stain notes - the target jars have the same name.
Proposed repo is OK (presumably because all uploads are forced to have
the artifact name and we don't have any destination overlaps).
Suggestion:
Only produce the zip version so there is exactly one "source release"
file and so only one to check.
Andy
Re: [VOTE] Release Apache Commons RDF 0.1.0-incubating RC2
Posted by Sergio Fernández <wi...@apache.org>.
+1 (binding)
so far I've checked:
* signatures and digests
* source releases file layouts
* matched git tags and commit ids
* incubator suffix
* NOTICE and LICENSE files
* build sources in a clean maven environment
On Thu, May 7, 2015 at 4:27 PM, Sergio Fernández <wi...@apache.org> wrote:
> Hello
>
> I am pleased to be calling this vote for the source release of Apache
> Commons RDF 0.1.0-incubating, composed by:
>
> * commons-rdf-api 0.1.0-incubating
> * commons-rdf-simple 0.1.0-incubating
>
> A candidate for the Commons RDF 0.1.0-incubating release is available at:
>
>
> https://dist.apache.org/repos/dist/dev/incubator/commonsrdf/0.1.0-incubating/
>
> The release candidate is based on the sources from commit
> 454ebc1ff457bcdb34f4671565bc984e6fbbcb77, tagged as 0.1.0-incubating, at:
>
> https://git-wip-us.apache.org/repos/asf/incubator-commonsrdf.git
>
> Release artifacts are signed with the keys available at:
>
> https://dist.apache.org/repos/dist/release/incubator/commonsrdf/KEYS
>
> A staged Maven repository is available for review at:
>
> https://repository.apache.org/content/repositories/orgapachecommons-1095
>
> The changelog for this version is available from JIRA:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316620&version=12332056
>
> Please vote on releasing this package as Apache Commons RDF
> 0.1.0-incubating. The vote is open for at least 72 hours and passes if a
> majority of at least three +1 IPMC votes are cast.
>
> [ ] +1 Release this package
> [ ] 0 I don't feel strongly about it, but I'm okay with the release
> [ ] -1 Do not release this package because...
>
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 6602747925
> e: sergio.fernandez@redlink.co
> w: http://redlink.co
>
--
Sergio Fernández
Partner Technology Manager
Redlink GmbH
m: +43 6602747925
e: sergio.fernandez@redlink.co
w: http://redlink.co