-1 (binding)

This is because the NOTICE file is missing at the top level of the karaf distro. In [1], it says "The NOTICE file must included within the distributed next to the LICENSE file."

I interpret that "must" as meaning we need to produce a new release candidate, so that the NOTICE file is at the root (next to the LICENSE file).

Very happy to change my vote (to "+1") if someone with better Apache knowledge tells me that it's ok to just have the NOTICE in ./META-INF/NOTICE.

Also, the karaf distro contains ./META-INF/LICENSE which is *just* the apache license, rather than also including the other 3rd party licenses (which is done in ./LICENSE, as per the instructions at [2]). Should we change that as well? Or should we delete the file ./META-INF/LICENSE?

---
Other than that, the release looks great - works a treat deploying to various clouds!

Aled

p.s. even if producing a new RC, I don't think it's worth changing the vagrant image - we can live with "ubuntu/wily64" for this release.

[1] http://www.apache.org/dev/release.html#attribution-notices
[2] http://www.apache.org/dev/release.html#distributing-code-under-several-licenses


On 07/12/2016 11:57, Geoff Macartney wrote:
thanks Richard,

I thought that would be the case but worth asking.  Hope the above PR will
address it and can be cherry-picked for the rc.

Geoff

On Wed, 7 Dec 2016 at 11:43 Richard Downer <rich...@apache.org> wrote:

Geoff, all,

It's generally required that release artifacts have the LICENSE and NOTICE
files in the root. Artifacts that are machine-read like JARs and their ilk
can be excepted, but they should instead have those files in the most
appropriate place - META-INF for JARs.

So this would be a release blocker, IMO. However I will at least look at
the release candidate and test it before casting a vote :-)

Richard.


On 7 December 2016 at 11:34, Geoff Macartney <
geoff.macart...@cloudsoftcorp.com> wrote:

Actually I see the Karaf distro does have a NOTICE file, it's just in the
META-INF directory.  Is there any rule that says the file must be in the
root directory?  Maybe it's fine as it is?

I've raised https://github.com/apache/brooklyn-dist/pull/68 in any case,
to
have a copy of NOTICE in the top level.



On Wed, 7 Dec 2016 at 10:17 Geoff Macartney <
geoff.macart...@cloudsoftcorp.com> wrote:

thanks Svet,

I'll say +0, think we should fix the NOTICE in Karaf distro.   No
strong
feeling as to what we should do with the Vagrant - while I agree it
would
be nice in general to have an up-to-date image in the Vagrant, if there
are
issues with Xenial and Vagrant then that particular upgrade might be
more
of a hindrance to users than a help.

My other checks done on this, for completeness' sake:


[x] Download links work.
[x] Binaries work. (classic launcher, Karaf, RPM build)
[x] Checksums and PGP signatures are valid.
[x] Expanded source archive matches contents of RC tag.
[x] Expanded source archive builds and passes tests.
[x] LICENSE is present and correct. (classic launcher, Karaf, RPM)
[x] NOTICE is present and correct, including copyright date (classic,
RPM;
for Karaf see [2] previously)
[x] All files have license headers where appropriate.
[-] All dependencies have compatible licenses.
[x] No compiled archives bundled in source archive.

Tested on Ubuntu (RPM on Centos7):

Classic launcher (tested with Java 7 & Java 8)
Catalog sample app 1 deployed on AWS
sample app 2 deployed on GCE
sample app 3 deployed on softlayer
sample app 4 deployed on openstack nova

Karaf launcher
sample app 1 deployed on BYON
sample app 2 deployed on AWS
sample app 3 deployed on GCE => not supported on Karaf; deployed
instead
on openstack nova
sample app 4 deployed on softlayer

RPM build:
RPM installs and runs Brooklyn successfully

Tests with "br" tool (on MacOS, Linux):
Catalog updates
Applications stopped
br app


Geoff


On Wed, 7 Dec 2016 at 07:31 Svetoslav Neykov <
svetoslav.ney...@cloudsoftcorp.com> wrote:

Geoff,

[1] Documentation and web site content is excluded on purpose.
[2] Yes it should. Good spot!

Svet.


On 6.12.2016 г., at 19:54, Geoff Macartney <
geoff.macart...@cloudsoftcorp.com> wrote:
A couple of questions:

[1] Should the apache-brooklyn-0.10.0-src archive contain the
brooklyn-docs? (It hasn't in previous releases, but still worth
asking.)
[2] Should the Karaf distro folder have its own copy of the NOTICE
file?

On Mon, 5 Dec 2016 at 11:52 Svetoslav Neykov <
svetoslav.ney...@cloudsoftcorp.com> wrote:

This is to call for a vote for the release of Apache Brooklyn
0.10.0.
This release comprises of a source code distribution, and a
corresponding
binary distribution, and Maven artifacts.

The source and binary distributions, including signatures, digests,
etc.
can
be found at:



https://dist.apache.org/repos/dist/dev/brooklyn/apache-
brooklyn-0.10.0-rc1
The artifact SHA-256 checksums are as follows:

  9b75abf099e1b0ac2ff3193ef58b53e4d323bd377faefac1672aef61d994b45c
*apache-brooklyn-0.10.0-1.noarch.rpm
  6d86188fe2e210fa3f0e40220d236c43512298da1c158c95f4497ea54c3882e7
*apache-brooklyn-0.10.0-rc1-bin.tar.gz
  5b37d0d2da964c91bc1655a5ce1bb277e5f84265906c479c697821a855235a2e
*apache-brooklyn-0.10.0-rc1-bin.zip
  f1d66690fbf4786b1abc762b2c215dd392e96c1ac0eee49088857c91594b4f79
*apache-brooklyn-0.10.0-rc1-karaf.tar.gz
  54d3b492e477c1877cb0bb9fd17063403596a02fbc3fdf9af588827053175bad
*apache-brooklyn-0.10.0-rc1-karaf.zip
  7d8ed704cc2146756f6ac6616de03c3d5d71953ff60094c1e017efdefb17c079
*apache-brooklyn-0.10.0-rc1-src.tar.gz
  a9e652596800010d01982703aaf90f0ca76e8d471b0399717c1d96619c72865c
*apache-brooklyn-0.10.0-rc1-src.zip
  55e5044ce2a6ae76886bb10d6e68582ef94b8f024513840c1aa8203c068eccd0
*apache-brooklyn-0.10.0-rc1-client-cli-linux.tar.gz
  45799528ed0444b6a600918d33419bcf4d7c0eaf5cb58620a2c9ae3f7320ca62
*apache-brooklyn-0.10.0-rc1-client-cli-linux.zip
  21bb2186787414226220101c6080ec0afffbb8d008c46a33a39b51bceb65600a
*apache-brooklyn-0.10.0-rc1-client-cli-macosx.tar.gz
  8d80ed81d5f1940700e838b3d6bf1255214706ede5a51a48bf46214a0b87d5c4
*apache-brooklyn-0.10.0-rc1-client-cli-macosx.zip
  a2cb0b1efc7f93da96cae2495e2db63834cfaec29b5eefcf8107f7bec38e6bd3
*apache-brooklyn-0.10.0-rc1-client-cli-windows.tar.gz
  61b96bc68306aedb0e3477083077c940893e27b1a58322ad296f120fd5f40978
*apache-brooklyn-0.10.0-rc1-client-cli-windows.zip
  13462d97693607a33d59a0a8288c20a2cd2d62607df796a5db5b332a183a7234
*apache-brooklyn-0.10.0-rc1-vagrant.tar.gz
  c67e134d4eb93ce1e6cc8124c31ca29bedd38bd2ea41eb9389a6335ee7c1ba0b
*apache-brooklyn-0.10.0-rc1-vagrant.zip

The Nexus staging repository for the Maven artifacts is located at:



https://repository.apache.org/content/repositories/
orgapachebrooklyn-1030
All release artifacts are signed with the key with the following
fingerprint:

    9F9C CBDA 89B3 0F81 162C  673C 0FE9 0F00 C0DE F000

KEYS file available here:

    https://dist.apache.org/repos/dist/release/brooklyn/KEYS


The artifacts were built from git commit IDs:

brooklyn: c496c5e9167f9320d08c21d5bce50f16a2325268
brooklyn-client: 0594d27aa68ac1c86e2b4672a447336042d92496
brooklyn-dist: 09a1ca89cd7d5a468438025d7f2121ec7c52ffc6
brooklyn-docs: f75d094f51c49cd5aa51e213bafc51da3d4ff01c
brooklyn-library: 1a1962382413b0e5adbfb52bb33968df265b35c5
brooklyn-server: 635068a6985edf2e5dfbb9598d8dde2890c32ad3
brooklyn-ui: a6e2e8bccfdd98b4f7155b5be86f5b85149e0f33
All of the above have been tagged as "apache-brooklyn-0.10.0-rc1"

Please vote on releasing this package as Apache Brooklyn 0.10.0.

The vote will be open for at least 72 hours.
[ ] +1 Release this package as Apache Brooklyn 0.10.0
[ ] +0 no opinion
[ ] -1 Do not release this package because ...


Thanks!
Svet.



CHECKLIST for reference

[ ] Download links work.
[ ] Binaries work.
[ ] Checksums and PGP signatures are valid.
[ ] Expanded source archive matches contents of RC tag.
[ ] Expanded source archive builds and passes tests.
[ ] LICENSE is present and correct.
[ ] NOTICE is present and correct, including copyright date.
[ ] All files have license headers where appropriate.
[ ] All dependencies have compatible licenses.
[ ] No compiled archives bundled in source archive.
[ ] I follow this project’s commits list.




Reply via email to