You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wookie.apache.org by Paul Sharples <p....@bolton.ac.uk> on 2011/07/11 11:44:55 UTC
[VOTE] Apache Wookie 0.9.0-incubating Release
This is the first incubator release for Apache Wookie, with the artifacts
being versioned as 0.9.0-incubating.
We are requesting a vote via wookie-dev for the release of the artifacts found here...
http://people.apache.org/~psharples/wookie/staging-area/0p9p0/rc3/
...as the final 0.9.0 release.
PGP release keys (signed using DDED352A):
http://people.apache.org/~psharples/wookie/staging-area/0p9p0/rc3/KEYS
Please take the time to verify the artifacts before casting your vote.
Vote will be open for 72 hours.
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)
Re: [VOTE] Apache Wookie 0.9.0-incubating Release
Posted by Ate Douma <at...@douma.nu>.
+1
Ate
On 07/11/2011 11:44 AM, Paul Sharples wrote:
> This is the first incubator release for Apache Wookie, with the artifacts
> being versioned as 0.9.0-incubating.
>
> We are requesting a vote via wookie-dev for the release of the artifacts found
> here...
>
> http://people.apache.org/~psharples/wookie/staging-area/0p9p0/rc3/
>
> ...as the final 0.9.0 release.
>
> PGP release keys (signed using DDED352A):
> http://people.apache.org/~psharples/wookie/staging-area/0p9p0/rc3/KEYS
>
> Please take the time to verify the artifacts before casting your vote.
>
> Vote will be open for 72 hours.
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
[RESULT] [VOTE] Apache Wookie 0.9.0-incubating Release
Posted by Paul Sharples <p....@bolton.ac.uk>.
The vote has closed with the following results:
IPMC Members/Mentors:
+1 [2]
0 [0]
-1 [0]
PPMC Members:
+1 [3]
0 [0]
-1 [0]
The vote is ****successful****
Voting Record:
Scott Wilson: +1
Kris Popat: +1
Raido Kuli: +1
**Ross Gardler: +1
**Ate Douma: +1
(**Denotes a Wookie Mentor)
Note: The original vote was kept open longer than the original 72 hours
to allow everyone to participate.
On 11/07/2011 10:44, Paul Sharples wrote:
> This is the first incubator release for Apache Wookie, with the artifacts
> being versioned as 0.9.0-incubating.
>
> We are requesting a vote via wookie-dev for the release of the
> artifacts found here...
>
> http://people.apache.org/~psharples/wookie/staging-area/0p9p0/rc3/
>
> ...as the final 0.9.0 release.
>
> PGP release keys (signed using DDED352A):
> http://people.apache.org/~psharples/wookie/staging-area/0p9p0/rc3/KEYS
>
> Please take the time to verify the artifacts before casting your vote.
>
> Vote will be open for 72 hours.
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
>
------------------------------------------------------------------------
No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 10.0.1390 / Virus Database: 1518/3801 - Release Date: 07/31/11
Re: [VOTE] Apache Wookie 0.9.0-incubating Release
Posted by Kris Popat <kj...@gmail.com>.
On 11 Jul 2011, at 10:44, Paul Sharples wrote:
> This is the first incubator release for Apache Wookie, with the artifacts
> being versioned as 0.9.0-incubating.
>
> We are requesting a vote via wookie-dev for the release of the artifacts found here...
>
> http://people.apache.org/~psharples/wookie/staging-area/0p9p0/rc3/
>
> ...as the final 0.9.0 release.
>
> PGP release keys (signed using DDED352A):
> http://people.apache.org/~psharples/wookie/staging-area/0p9p0/rc3/KEYS
>
> Please take the time to verify the artifacts before casting your vote.
>
> Vote will be open for 72 hours.
[ x] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)
Re: [VOTE] Apache Wookie 0.9.0-incubating Release
Posted by Scott Wilson <sc...@gmail.com>.
On 11 Jul 2011, at 10:44, Paul Sharples wrote:
> This is the first incubator release for Apache Wookie, with the artifacts
> being versioned as 0.9.0-incubating.
>
> We are requesting a vote via wookie-dev for the release of the artifacts found here...
>
> http://people.apache.org/~psharples/wookie/staging-area/0p9p0/rc3/
>
> ...as the final 0.9.0 release.
>
> PGP release keys (signed using DDED352A):
> http://people.apache.org/~psharples/wookie/staging-area/0p9p0/rc3/KEYS
>
> Please take the time to verify the artifacts before casting your vote.
>
> Vote will be open for 72 hours.
[X] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)
All signatures verify with gpg, I can build and run src, and run the war and standalone versions.
>
>
Re: [DISCUSS] Apache Wookie 0.9.0-incubating Release: packaging and
license/notice files
Posted by Ate Douma <at...@douma.nu>.
On 07/28/2011 11:01 AM, Paul Sharples wrote:
> On 28/07/2011 01:17, Ate Douma wrote:
>
>> * NOTICE/LICENSE/RUNTIME_LICENSE files in general:
>> The current ASF policy is that these files only need/should attribute whatever
>> is actually packaged (note: this equally concerns the svn tree, which in
>> itself can and should be regarded as a "distribution"). Anything not
>> "packaged" need (should) not be attributed. These files serve a legal purpose
>> only, and anything not needed and/or redundant will only make it more
>> difficult to maintain and validate and properly.
>> Dependencies not packaged/distributed, but for instance needed (only) for
>> building is not required to be attributed in these files. If there are
>> specific (buid/runtime) requirements users should be aware of then those
>> should be mentioned and explained in additional README, BUILD_NOTES, etc.
>> files, only.
>>
>
> just to be clear, are you are talking about libraries we have used to build the
> (war and standalone) binaries here and so don't need to be mentioned in any of
> the licence files. Instead we would explain what is needed in the README,
> BUILD_NOTES - and in theory would only be needed to rebuild the source?
>
Yes, and not just for building but (possibly) even for running.
For instance, the war binary does depend on the servlet/jsp api but those are
assumed (required actually) to be provided by the web container itself. So there
is no need to attribute those, at most only mentioning the version which the war
would depend on (e.g. servlet api 2.5).
For building, you also won't need to specify or even mention every single
dependency (in README/BUILD_NOTES, etc.) if its either transparent or obvious
and won't have any possible license/notice requirements.
An ASF based but external test-harness dependency like jmeter, which would be
automatically be downloaded by Ivy or Maven isn't required to be mentioned
(although it might be nice to give credit), but possibly an automated download
of a mysql jdbc driver (for *testing* purposes only) might require mentioning.
HTH,
Ate
Re: [DISCUSS] Apache Wookie 0.9.0-incubating Release: packaging and
license/notice files
Posted by Paul Sharples <p....@bolton.ac.uk>.
On 28/07/2011 01:17, Ate Douma wrote:
> Hi Paul, all,
>
> I've finally found some time to review the release artifacts and
> before I *will* vote +1 on it, I want to share some of my findings
> concerning the current license/notice attributions and packaging in
> general.
>
> I'm sorry I didn't have time to properly review these much earlier but
> there are several things concerning the handling of the license and
> notice requirements which IMO could and probably should be done a
> little bit different.
>
> AFAIK, none of the suggestions I'd like to give below require
> canceling this release, as one way or the other the *overall* coverage
> of the license and notice requirements seem pretty good, albeit IMO
> somewhat overdone in some area's.
>
> So, please take the following suggestions as something to consider for
> the next release. And to be clear, I'm not an absolute expert in this
> area either, so I happily will hear others view on these. I'm not
> claiming everything I say below is actually correct, they are just
> represent *my* interpretation of what is needed, and what might be not.
>
>
> * KEYS file packaged with every release artifact:
> Having a KEYS file *within* a release artifact makes no much sense:
> its whole purpose is to validate a signed release artifact itself, so
> embedding it within is meaningless.
> Most/all projects keep the KEYS file within svn outside the trunk
> folders, e.g. like in the svn root folder or a separate sub folder
> thereof,
> e.g. like http://svn.apache.org/repos/asf/incubator/rave/KEYS.
ok, will note for next time
>
> * wookie.war has DISCLAIMER/LICENSE/NOTICE/RUNTIME_LICENSE files in
> root folder:
> Having these files in the war root means these will be accessible as
> web resources... While still pretty harmless in this case/release, its
> a bad practice and could actually pose a security issue as everyone
> can thereby find/read which runtime artifacts (including there
> version) are in use.
> The expected/advised location for these files would be under /META-INF.
>
will note for next time
> * NOTICE/LICENSE/RUNTIME_LICENSE files in general:
> The current ASF policy is that these files only need/should attribute
> whatever is actually packaged (note: this equally concerns the svn
> tree, which in itself can and should be regarded as a "distribution").
> Anything not "packaged" need (should) not be attributed. These files
> serve a legal purpose only, and anything not needed and/or redundant
> will only make it more difficult to maintain and validate and properly.
> Dependencies not packaged/distributed, but for instance needed (only)
> for building is not required to be attributed in these files. If there
> are specific (buid/runtime) requirements users should be aware of then
> those should be mentioned and explained in additional README,
> BUILD_NOTES, etc. files, only.
>
just to be clear, are you are talking about libraries we have used to
build the (war and standalone) binaries here and so don't need to be
mentioned in any of the licence files. Instead we would explain what is
needed in the README, BUILD_NOTES - and in theory would only be needed
to rebuild the source?
> * License attribution to other ASF projects packaged sources/artifacts:
> From a legal POV, this is not needed: the basic (required) NOTICE and
> LICENSE attribution that the distribution includes ASF produces
> software under the ASL 2.0 license already covers all legal requirements.
> While mentioning each and every other ASF project source/artifact in
> the LICENSE files is not harmful in anyway, it is a lot of extra and
> unneeded effort not easy to maintain properly.
>
ok, will drop for next time
> For example, the LICENSE file does mention the
> shindig-common-1.1-BETA5-incubating.jar (which is *not* packaged in
> the source distribution, more about that below), but does not mention
> shindig/dist/shindig-features-1.1-BETA5-incubating.jar which *is*
> packaged in the source distribution. However neither is really
> problematic as isn't needed
> anyway :)
> Another example is some extra jackrabbit jars which are not mentioned
> in either the LICENSE or RUNTIME_LICENSE file but are packaged with
> the binary distributions.
> And while commons-io and commons-email are mentioned in the LICENSE
> file (but not packaged in the source distribution), they are not
> mentioned in the RUNTIME_LICENSE file while they *are* packaged in the
> binary distributions.
>
Yes, we had already done some work on getting rid of some of these
dependencies. We had already planned to refine this for the next
release, so it's on the radar already.
> * RUNTIME_LICENSE file:
> - The RUNTIME_LICENSE file is used/intended to cover the requirements
> for (both) the binary distributions, wookie war/standalone.
> However, as a single file it covers both distributions while the war
> distribution does not package several artifacts (and thus licenses)
> contained in the standalone distribution (Eclipsse, Jetty, Servlet/JSP
> etc.)
> From a legal POV, this is not "wrong", but AFAIK not ideal either.
> To "solve" this however would require maintaining two separate
> RUNTIME_LICENSE files which isn't ideal either. I have no strong
> opinion on this but it might be considered to split these files up if
> causing not too much of a burden to maintain.
we can look in to doing this
> - More/most serious is the omission of the 3rd party license
> attributions for many (all?) of the packaged Widgets in the
> RUNTIME_LICENSE file. While these are distributed as "source", they
> are (thereby) packaged in the binary distributions and as such
> *should* be attributed in the RUNTIME_LICENSE file. However, as these
> 3rd party licenses are properly mentioned in the LICENSE file which
> also is packaged in the binary distribution, legally everything
> probably is still OK, even if somewhat confusing.
> - My suggestion for future releases however is to consider packaging
> only a is single LICENSE file within a release artifact/distribution
> and thus maintain separate LICENSE files for source and binary
> distributions (optionally even two for the latter). And the same holds
> for the NOTICE file which currently also covers everything for both
> source and binary distributions.
>
ok, I think your suggestion is valid.
>
> Overall I think the legal LICENSE and NOTICE requirements however
> still are met satisfactory enough for this first incubator release.
> And as building the source and executing and testing both the war and
> standalone worked fine for me, I'll vote +1 for the release right
> after I send off this feedback.
thanks
>
> With kind regards,
>
> Ate
>
>
> On 07/11/2011 11:44 AM, Paul Sharples wrote:
>> This is the first incubator release for Apache Wookie, with the
>> artifacts
>> being versioned as 0.9.0-incubating.
>>
>> We are requesting a vote via wookie-dev for the release of the
>> artifacts found
>> here...
>>
>> http://people.apache.org/~psharples/wookie/staging-area/0p9p0/rc3/
>>
>> ...as the final 0.9.0 release.
>>
>> PGP release keys (signed using DDED352A):
>> http://people.apache.org/~psharples/wookie/staging-area/0p9p0/rc3/KEYS
>>
>> Please take the time to verify the artifacts before casting your vote.
>>
>> Vote will be open for 72 hours.
>>
>> [ ] +1 approve
>> [ ] +0 no opinion
>> [ ] -1 disapprove (and reason why)
>>
>
>
[DISCUSS] Apache Wookie 0.9.0-incubating Release: packaging and license/notice
files
Posted by Ate Douma <at...@douma.nu>.
Hi Paul, all,
I've finally found some time to review the release artifacts and before I *will*
vote +1 on it, I want to share some of my findings concerning the current
license/notice attributions and packaging in general.
I'm sorry I didn't have time to properly review these much earlier but there are
several things concerning the handling of the license and notice requirements
which IMO could and probably should be done a little bit different.
AFAIK, none of the suggestions I'd like to give below require canceling this
release, as one way or the other the *overall* coverage of the license and
notice requirements seem pretty good, albeit IMO somewhat overdone in some area's.
So, please take the following suggestions as something to consider for the next
release. And to be clear, I'm not an absolute expert in this area either, so I
happily will hear others view on these. I'm not claiming everything I say below
is actually correct, they are just represent *my* interpretation of what is
needed, and what might be not.
* KEYS file packaged with every release artifact:
Having a KEYS file *within* a release artifact makes no much sense: its whole
purpose is to validate a signed release artifact itself, so embedding it within
is meaningless.
Most/all projects keep the KEYS file within svn outside the trunk folders, e.g.
like in the svn root folder or a separate sub folder thereof,
e.g. like http://svn.apache.org/repos/asf/incubator/rave/KEYS.
* wookie.war has DISCLAIMER/LICENSE/NOTICE/RUNTIME_LICENSE files in root folder:
Having these files in the war root means these will be accessible as web
resources... While still pretty harmless in this case/release, its a bad
practice and could actually pose a security issue as everyone can thereby
find/read which runtime artifacts (including there version) are in use.
The expected/advised location for these files would be under /META-INF.
* NOTICE/LICENSE/RUNTIME_LICENSE files in general:
The current ASF policy is that these files only need/should attribute whatever
is actually packaged (note: this equally concerns the svn tree, which in itself
can and should be regarded as a "distribution"). Anything not "packaged" need
(should) not be attributed. These files serve a legal purpose only, and anything
not needed and/or redundant will only make it more difficult to maintain and
validate and properly.
Dependencies not packaged/distributed, but for instance needed (only) for
building is not required to be attributed in these files. If there are specific
(buid/runtime) requirements users should be aware of then those should be
mentioned and explained in additional README, BUILD_NOTES, etc. files, only.
* License attribution to other ASF projects packaged sources/artifacts:
From a legal POV, this is not needed: the basic (required) NOTICE and LICENSE
attribution that the distribution includes ASF produces software under the ASL
2.0 license already covers all legal requirements.
While mentioning each and every other ASF project source/artifact in the LICENSE
files is not harmful in anyway, it is a lot of extra and unneeded effort not
easy to maintain properly.
For example, the LICENSE file does mention the
shindig-common-1.1-BETA5-incubating.jar (which is *not* packaged in the source
distribution, more about that below), but does not mention
shindig/dist/shindig-features-1.1-BETA5-incubating.jar which *is* packaged in
the source distribution. However neither is really problematic as isn't needed
anyway :)
Another example is some extra jackrabbit jars which are not mentioned in either
the LICENSE or RUNTIME_LICENSE file but are packaged with the binary distributions.
And while commons-io and commons-email are mentioned in the LICENSE file (but
not packaged in the source distribution), they are not mentioned in the
RUNTIME_LICENSE file while they *are* packaged in the binary distributions.
* RUNTIME_LICENSE file:
- The RUNTIME_LICENSE file is used/intended to cover the requirements for (both)
the binary distributions, wookie war/standalone.
However, as a single file it covers both distributions while the war
distribution does not package several artifacts (and thus licenses) contained in
the standalone distribution (Eclipsse, Jetty, Servlet/JSP etc.)
From a legal POV, this is not "wrong", but AFAIK not ideal either.
To "solve" this however would require maintaining two separate RUNTIME_LICENSE
files which isn't ideal either. I have no strong opinion on this but it might be
considered to split these files up if causing not too much of a burden to maintain.
- More/most serious is the omission of the 3rd party license attributions for
many (all?) of the packaged Widgets in the RUNTIME_LICENSE file. While these are
distributed as "source", they are (thereby) packaged in the binary distributions
and as such *should* be attributed in the RUNTIME_LICENSE file. However, as
these 3rd party licenses are properly mentioned in the LICENSE file which also
is packaged in the binary distribution, legally everything probably is still OK,
even if somewhat confusing.
- My suggestion for future releases however is to consider packaging only a is
single LICENSE file within a release artifact/distribution and thus maintain
separate LICENSE files for source and binary distributions (optionally even two
for the latter). And the same holds for the NOTICE file which currently also
covers everything for both source and binary distributions.
Overall I think the legal LICENSE and NOTICE requirements however still are met
satisfactory enough for this first incubator release.
And as building the source and executing and testing both the war and standalone
worked fine for me, I'll vote +1 for the release right after I send off this
feedback.
With kind regards,
Ate
On 07/11/2011 11:44 AM, Paul Sharples wrote:
> This is the first incubator release for Apache Wookie, with the artifacts
> being versioned as 0.9.0-incubating.
>
> We are requesting a vote via wookie-dev for the release of the artifacts found
> here...
>
> http://people.apache.org/~psharples/wookie/staging-area/0p9p0/rc3/
>
> ...as the final 0.9.0 release.
>
> PGP release keys (signed using DDED352A):
> http://people.apache.org/~psharples/wookie/staging-area/0p9p0/rc3/KEYS
>
> Please take the time to verify the artifacts before casting your vote.
>
> Vote will be open for 72 hours.
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
Re: [VOTE] Apache Wookie 0.9.0-incubating Release
Posted by Raido Kuli <ra...@gmail.com>.
+1
--
Raido
On 19.07.2011, at 16:52, Ross Gardler wrote:
> +1
>
> Thanks Paul.
>
> Ross
>
> On 11 July 2011 10:44, Paul Sharples <p....@bolton.ac.uk> wrote:
>> This is the first incubator release for Apache Wookie, with the artifacts
>> being versioned as 0.9.0-incubating.
>>
>> We are requesting a vote via wookie-dev for the release of the artifacts
>> found here...
>>
>> http://people.apache.org/~psharples/wookie/staging-area/0p9p0/rc3/
>>
>> ...as the final 0.9.0 release.
>>
>> PGP release keys (signed using DDED352A):
>> http://people.apache.org/~psharples/wookie/staging-area/0p9p0/rc3/KEYS
>>
>> Please take the time to verify the artifacts before casting your vote.
>>
>> Vote will be open for 72 hours.
>>
>> [ ] +1 approve
>> [ ] +0 no opinion
>> [ ] -1 disapprove (and reason why)
>>
>>
>
>
>
> --
> Ross Gardler (@rgardler)
> Programme Leader (Open Development)
> OpenDirective http://opendirective.com
Re: [VOTE] Apache Wookie 0.9.0-incubating Release
Posted by Ross Gardler <rg...@opendirective.com>.
+1
Thanks Paul.
Ross
On 11 July 2011 10:44, Paul Sharples <p....@bolton.ac.uk> wrote:
> This is the first incubator release for Apache Wookie, with the artifacts
> being versioned as 0.9.0-incubating.
>
> We are requesting a vote via wookie-dev for the release of the artifacts
> found here...
>
> http://people.apache.org/~psharples/wookie/staging-area/0p9p0/rc3/
>
> ...as the final 0.9.0 release.
>
> PGP release keys (signed using DDED352A):
> http://people.apache.org/~psharples/wookie/staging-area/0p9p0/rc3/KEYS
>
> Please take the time to verify the artifacts before casting your vote.
>
> Vote will be open for 72 hours.
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
>
>
--
Ross Gardler (@rgardler)
Programme Leader (Open Development)
OpenDirective http://opendirective.com