You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wookie.apache.org by Ate Douma <at...@douma.nu> on 2012/02/09 12:51:05 UTC
Reviewing release candidate
I'm trying to review the current wookie trunk on LICENSE and NOTICE requirements
for the next release.
First question I have is: how do I 'build' a release binary?
From ant -p I don't see a build target which should do that.
To be able to properly review what will end up in the binary release, I need to
be able to build that myself, or have to wait until a candidate is prepared by
others. I'd like to do it myself :)
It would also be nice if a release-management kind of documentation could be
published on the website, kind of similar to what we have for Rave [1].
As a start I looked briefly at the root NOTICE file which raises a few
suggestions and questions already:
- Bubbles.wgt notice
I looked the provided url up but couldn't find any license or notice whatsoever
for inclusion/usage of this widget, and neither does the .wgt has anything
embedded. Where did this *required* notice come from (note: only *required*
notices should be added to the NOTICE file)
- many/most of the other notices seems to be for MIT/BSD licensed stuff
Those should not need notices, unless (extra) explicitly required and/or coming
with a NOTICE (file) of their own. In general, if for these products their
license (with copyright statement) is included in our LICENSE file, there is no
need to also add a notice in the NOTICE file. AFAIK the /LICENSE file already
takes care of that properly, +1 on that.
In general, the NOTICE file should not be used for providing friendly credits.
This file has a legal purpose only.
If we want to give friendly but non-required credits, the README file can/should
be used for that instead.
Anything we add to our NOTICE (required or not) we force upon our downstream
users to keep as specified by our AS 2.0 license section 4d.
This is why more recently there is more attention for making sure we only put
really required entries in the NOTICE file, to lessen the burden for our
downstream users.
Ate
Re: Reviewing release candidate
Posted by Paul Sharples <p....@bolton.ac.uk>.
On 09/02/2012 11:51, Ate Douma wrote:
> I'm trying to review the current wookie trunk on LICENSE and NOTICE
> requirements for the next release.
>
> First question I have is: how do I 'build' a release binary?
> From ant -p I don't see a build target which should do that.
>
> To be able to properly review what will end up in the binary release,
> I need to be able to build that myself, or have to wait until a
> candidate is prepared by others. I'd like to do it myself :)
Ate,
We need to document this you are correct. there are two ant tasks to
build things, one for non-maven artifacts, one for maven artifacts.
non maven
==========
At the top level run 'ant build-release-all'
This should create a folder at the top level called "release". This
should contain all the src, standalone and war builds.
For the maven artifacts
====================
At the top level run 'ant publish-local'
This should create the maven (intended) builds in your local jar
repository. On my machine this is found here...
C:\Users\paul\.m2\repository\org\apache\wookie
Found under here should be 3 folders - one for the connector, one for
the parser and one for a self contained wookie.war file.
For the maven artifacts there are similar tasks for creating/deploying
snapshots & deploying (signed versions) to the staging area.
Paul
>
> It would also be nice if a release-management kind of documentation
> could be published on the website, kind of similar to what we have for
> Rave [1].
>
> As a start I looked briefly at the root NOTICE file which raises a few
> suggestions and questions already:
>
> - Bubbles.wgt notice
> I looked the provided url up but couldn't find any license or notice
> whatsoever for inclusion/usage of this widget, and neither does the
> .wgt has anything embedded. Where did this *required* notice come from
> (note: only *required* notices should be added to the NOTICE file)
>
> - many/most of the other notices seems to be for MIT/BSD licensed stuff
> Those should not need notices, unless (extra) explicitly required
> and/or coming with a NOTICE (file) of their own. In general, if for
> these products their license (with copyright statement) is included in
> our LICENSE file, there is no need to also add a notice in the NOTICE
> file. AFAIK the /LICENSE file already takes care of that properly, +1
> on that.
>
> In general, the NOTICE file should not be used for providing friendly
> credits. This file has a legal purpose only.
>
> If we want to give friendly but non-required credits, the README file
> can/should be used for that instead.
>
> Anything we add to our NOTICE (required or not) we force upon our
> downstream users to keep as specified by our AS 2.0 license section 4d.
> This is why more recently there is more attention for making sure we
> only put really required entries in the NOTICE file, to lessen the
> burden for our downstream users.
>
> Ate
>
Re: Reviewing release candidate
Posted by Ate Douma <at...@douma.nu>.
On 02/09/2012 01:08 PM, Scott Wilson wrote:
>
> On 9 Feb 2012, at 11:51, Ate Douma wrote:
>
>> I'm trying to review the current wookie trunk on LICENSE and NOTICE requirements for the next release.
>>
>> First question I have is: how do I 'build' a release binary?
>> From ant -p I don't see a build target which should do that.
>
> Try:
>
> ant build-release-all
>
> This creates src, war and standalone release packages in the release folder
>
Thanks, that works!
Weird that ant -p doesn't report that as target, but I'm not accustomed to use
ant (in a long time) anymore, so probably I shouldn't expect that anyway.
Makes it even more needed to have extensive developer and release-management
documentation IMO.
>>
>> To be able to properly review what will end up in the binary release, I need to be able to build that myself, or have to wait until a candidate is prepared by others. I'd like to do it myself :)
>
> Indeed :-)
>
>>
>> It would also be nice if a release-management kind of documentation could be published on the website, kind of similar to what we have for Rave [1].
>
> +1
>
>>
>> As a start I looked briefly at the root NOTICE file which raises a few suggestions and questions already:
>>
>> - Bubbles.wgt notice
>> I looked the provided url up but couldn't find any license or notice whatsoever for inclusion/usage of this widget, and neither does the .wgt has anything embedded. Where did this *required* notice come from (note: only *required* notices should be added to the NOTICE file)
>
> The widget isn't published on Opera any more, it was replaced by a later version that doesn't seem to have any associated license info, so I've kept the older version I took from Opera which did contain the original license and notices we've retained, rather than try and update it.
>
Got it.
>>
>> - many/most of the other notices seems to be for MIT/BSD licensed stuff
>> Those should not need notices, unless (extra) explicitly required and/or coming with a NOTICE (file) of their own. In general, if for these products their license (with copyright statement) is included in our LICENSE file, there is no need to also add a notice in the NOTICE file. AFAIK the /LICENSE file already takes care of that properly, +1 on that.
>
>
>> In general, the NOTICE file should not be used for providing friendly credits. This file has a legal purpose only.
>>
>> If we want to give friendly but non-required credits, the README file can/should be used for that instead.
>>
>> Anything we add to our NOTICE (required or not) we force upon our downstream users to keep as specified by our AS 2.0 license section 4d.
>> This is why more recently there is more attention for making sure we only put really required entries in the NOTICE file, to lessen the burden for our downstream users.
>>
>
> Thanks Ate, I did wonder about that as I was following the discussions about the Rave NOTICE file. I'll create a Jira issue for it now.
Great. And I see you're already cleaning up :)
I'll pick up further reviewing sometime later but its getting to look good.
Template filtering (WOOKIE-314) also added, good stuff!
Ate
>
>> Ate
>
Re: Reviewing release candidate
Posted by Scott Wilson <sc...@gmail.com>.
On 9 Feb 2012, at 11:51, Ate Douma wrote:
> I'm trying to review the current wookie trunk on LICENSE and NOTICE requirements for the next release.
>
> First question I have is: how do I 'build' a release binary?
> From ant -p I don't see a build target which should do that.
Try:
ant build-release-all
This creates src, war and standalone release packages in the release folder
>
> To be able to properly review what will end up in the binary release, I need to be able to build that myself, or have to wait until a candidate is prepared by others. I'd like to do it myself :)
Indeed :-)
>
> It would also be nice if a release-management kind of documentation could be published on the website, kind of similar to what we have for Rave [1].
+1
>
> As a start I looked briefly at the root NOTICE file which raises a few suggestions and questions already:
>
> - Bubbles.wgt notice
> I looked the provided url up but couldn't find any license or notice whatsoever for inclusion/usage of this widget, and neither does the .wgt has anything embedded. Where did this *required* notice come from (note: only *required* notices should be added to the NOTICE file)
The widget isn't published on Opera any more, it was replaced by a later version that doesn't seem to have any associated license info, so I've kept the older version I took from Opera which did contain the original license and notices we've retained, rather than try and update it.
>
> - many/most of the other notices seems to be for MIT/BSD licensed stuff
> Those should not need notices, unless (extra) explicitly required and/or coming with a NOTICE (file) of their own. In general, if for these products their license (with copyright statement) is included in our LICENSE file, there is no need to also add a notice in the NOTICE file. AFAIK the /LICENSE file already takes care of that properly, +1 on that.
> In general, the NOTICE file should not be used for providing friendly credits. This file has a legal purpose only.
>
> If we want to give friendly but non-required credits, the README file can/should be used for that instead.
>
> Anything we add to our NOTICE (required or not) we force upon our downstream users to keep as specified by our AS 2.0 license section 4d.
> This is why more recently there is more attention for making sure we only put really required entries in the NOTICE file, to lessen the burden for our downstream users.
>
Thanks Ate, I did wonder about that as I was following the discussions about the Rave NOTICE file. I'll create a Jira issue for it now.
> Ate
Re: Reviewing release candidate
Posted by Scott Wilson <sc...@gmail.com>.
On 10 Feb 2012, at 12:23, Ate Douma wrote:
> On 02/10/2012 01:18 PM, Ate Douma wrote:
>> On 02/10/2012 11:04 AM, Paul Sharples wrote:
>>> On 09/02/2012 11:51, Ate Douma wrote:
>>>> I'm trying to review the current wookie trunk on LICENSE and NOTICE
>>>> requirements for the next release.
>>>
>>> All Jira issues are now dealt with and the Rat report now looks ok.
>>> Do we need more time for reviewing or are we ready to cut a release?
>
> It also seems to me WOOKIE-314 should be fixed, right?
> Note that it doesn't have its Fix Version set, which makes it not show up on the issues for 0.9.2
I don't think we need to hold up this release for it - I've set it to fix in 0.10
>
>>
>> I'd like to give it one more thorough review, which I'll try to finish before
>> end of this working day.
>>
>> Ate
>>
>> p.s. I suggest someone adds the /release folder to svn:ignore.
>> It now shows up as a svn modification.
>>
>>>
>>> Paul
>>>
>>>>
>>>> First question I have is: how do I 'build' a release binary?
>>>> From ant -p I don't see a build target which should do that.
>>>>
>>>> To be able to properly review what will end up in the binary release, I need
>>>> to be able to build that myself, or have to wait until a candidate is prepared
>>>> by others. I'd like to do it myself :)
>>>>
>>>> It would also be nice if a release-management kind of documentation could be
>>>> published on the website, kind of similar to what we have for Rave [1].
>>>>
>>>> As a start I looked briefly at the root NOTICE file which raises a few
>>>> suggestions and questions already:
>>>>
>>>> - Bubbles.wgt notice
>>>> I looked the provided url up but couldn't find any license or notice
>>>> whatsoever for inclusion/usage of this widget, and neither does the .wgt has
>>>> anything embedded. Where did this *required* notice come from (note: only
>>>> *required* notices should be added to the NOTICE file)
>>>>
>>>> - many/most of the other notices seems to be for MIT/BSD licensed stuff
>>>> Those should not need notices, unless (extra) explicitly required and/or
>>>> coming with a NOTICE (file) of their own. In general, if for these products
>>>> their license (with copyright statement) is included in our LICENSE file,
>>>> there is no need to also add a notice in the NOTICE file. AFAIK the /LICENSE
>>>> file already takes care of that properly, +1 on that.
>>>>
>>>> In general, the NOTICE file should not be used for providing friendly credits.
>>>> This file has a legal purpose only.
>>>>
>>>> If we want to give friendly but non-required credits, the README file
>>>> can/should be used for that instead.
>>>>
>>>> Anything we add to our NOTICE (required or not) we force upon our downstream
>>>> users to keep as specified by our AS 2.0 license section 4d.
>>>> This is why more recently there is more attention for making sure we only put
>>>> really required entries in the NOTICE file, to lessen the burden for our
>>>> downstream users.
>>>>
>>>> Ate
>>>>
>>>
>>
>
Re: Reviewing release candidate
Posted by Ate Douma <at...@douma.nu>.
On 02/10/2012 01:18 PM, Ate Douma wrote:
> On 02/10/2012 11:04 AM, Paul Sharples wrote:
>> On 09/02/2012 11:51, Ate Douma wrote:
>>> I'm trying to review the current wookie trunk on LICENSE and NOTICE
>>> requirements for the next release.
>>
>> All Jira issues are now dealt with and the Rat report now looks ok.
>> Do we need more time for reviewing or are we ready to cut a release?
It also seems to me WOOKIE-314 should be fixed, right?
Note that it doesn't have its Fix Version set, which makes it not show up on the
issues for 0.9.2
>
> I'd like to give it one more thorough review, which I'll try to finish before
> end of this working day.
>
> Ate
>
> p.s. I suggest someone adds the /release folder to svn:ignore.
> It now shows up as a svn modification.
>
>>
>> Paul
>>
>>>
>>> First question I have is: how do I 'build' a release binary?
>>> From ant -p I don't see a build target which should do that.
>>>
>>> To be able to properly review what will end up in the binary release, I need
>>> to be able to build that myself, or have to wait until a candidate is prepared
>>> by others. I'd like to do it myself :)
>>>
>>> It would also be nice if a release-management kind of documentation could be
>>> published on the website, kind of similar to what we have for Rave [1].
>>>
>>> As a start I looked briefly at the root NOTICE file which raises a few
>>> suggestions and questions already:
>>>
>>> - Bubbles.wgt notice
>>> I looked the provided url up but couldn't find any license or notice
>>> whatsoever for inclusion/usage of this widget, and neither does the .wgt has
>>> anything embedded. Where did this *required* notice come from (note: only
>>> *required* notices should be added to the NOTICE file)
>>>
>>> - many/most of the other notices seems to be for MIT/BSD licensed stuff
>>> Those should not need notices, unless (extra) explicitly required and/or
>>> coming with a NOTICE (file) of their own. In general, if for these products
>>> their license (with copyright statement) is included in our LICENSE file,
>>> there is no need to also add a notice in the NOTICE file. AFAIK the /LICENSE
>>> file already takes care of that properly, +1 on that.
>>>
>>> In general, the NOTICE file should not be used for providing friendly credits.
>>> This file has a legal purpose only.
>>>
>>> If we want to give friendly but non-required credits, the README file
>>> can/should be used for that instead.
>>>
>>> Anything we add to our NOTICE (required or not) we force upon our downstream
>>> users to keep as specified by our AS 2.0 license section 4d.
>>> This is why more recently there is more attention for making sure we only put
>>> really required entries in the NOTICE file, to lessen the burden for our
>>> downstream users.
>>>
>>> Ate
>>>
>>
>
Re: Reviewing release candidate
Posted by Ate Douma <at...@douma.nu>.
On 02/14/2012 06:55 PM, Paul Sharples wrote:
> On 14/02/2012 16:55, Scott Wilson wrote:
>> On 14 Feb 2012, at 14:40, Paul Sharples wrote:
>>
>>> On 13/02/2012 18:09, Paul Sharples wrote:
>>>> I'll assume lazy consensus and make the artifacts tomorrow. (unless someone
>>>> finds an issue before then)
>>>>
>>>> Paul
>>>>
>>> I've found a licence issue while making the maven war artifact. As you know
>>> we make a war release using our 'ant build-release-war' task. This artifact
>>> is then usually located up at the normal apache download area.
>>> (http://www.apache.org/dist/incubator/wookie/version/binary/war) This
>>> artifact is aimed at a typical mysql/tomcat configuration and assumes that
>>> the user will deploy the war in that kind of setup. As far as I can tell, the
>>> NOTICE file is okay for this.
>>>
>>> However, the *new* maven war artifact we make is slightly different in that
>>> it is intended to be self contained and as such uses an embedded derby db
>>> (the maven artifact contains a 'derby-10.4.2.0.jar' file, while the other war
>>> distro does not) While reviewing the NOTICE file for this artifact I see that
>>> the reference to derby (as found in the standalone NOTICE file) is not present.
>>>
>>> i.e the following text...
>>>
>>> This software contains unmodified binary redistributions of software (Derby)
>>> developed by
>>> The Apache Software Foundation (http://www.apache.org/):
>>>
>>> ==============================================================
>>> Apache Derby
>>> Copyright 2004-2008 The Apache Software Foundation
>>> ==============================================================
>>>
>>> Portions of Derby were originally developed by
>>> International Business Machines Corporation and are
>>> licensed to the Apache Software Foundation under the
>>> "Software Grant and Corporate Contribution License Agreement",
>>> informally known as the "Derby CLA".
>>> The following copyright notice(s) were affixed to portions of the code
>>> with which this file is now or was at one time distributed
>>> and are placed here unaltered.
>>>
>>> (C) Copyright 1997,2004 International Business Machines Corporation. All
>>> rights reserved.
>>>
>>> (C) Copyright IBM Corp. 2003.
>>>
>>> The portion of the functionTests under 'nist' was originally
>>> developed by the National Institute of Standards and Technology (NIST),
>>> an agency of the United States Department of Commerce, and adapted by
>>> International Business Machines Corporation in accordance with the NIST
>>> Software Acknowledgment and Redistribution document at
>>> http://www.itl.nist.gov/div897/ctg/sql_form.htm
>>>
>>> I can quite easily add that text to the maven war artifact LICENSE before
>>> uploading to the staging area, but then the tagged '0.9.2-incubating'
>>> etc/release/war/LICENSE would be slightly different from the one found in the
>>> maven war build.
And it should be different: these artifacts are different.
The question is: should they be different?
I think it is rather confusing to have two different wookie.war distributions,
one with an embedded derby and another without (but configured for mysql).
For the next release we should think out a better and easier to manage way of
setting up the database configuration such that there only is a single/standard
war artifact needed.
>> I think you meant NOTICE? There is no additional LICENSE requirement for Derby.
>
> Oops, Yes i did mean NOTICE, i started the email by referencing the correct
> NOTICE file and then for some reason swapped to referring to it as LICENSE, my bad.
>
>>
>> As it only affects one of the binary releases and not the source release, I
>> would have thought we could get away with fixing this in the release artifact
>> rather than starting another tag?
>
Patching the maven war artifact with an updated NOTICE file, although not
'pretty' IMO should be acceptable, in this case and certainly for this release.
For the next release it would be better to have this 'fixed' though. Less
chances of mistakes.
> For me its a trivial change, I but wanted to check with other IPMC members that
> it would be ok to do this. (I'd rather get this clear than risk people voting -1
> to the whole thing when we start the vote)
I'm OK with it.
>
>>
>>
>>> *If* we can't change this now, does this mean we should drop the maven WAR
>>> artifact for this release? (this doesn't affect anything else)
If we couldn't get away with it (but I think we can), then instead I would have
suggested to just drop the tag, fix it in trunk and then recreate the tag.
As long as there hasn't been send out an official VOTE thread, this 'trick' is
applied by other projects as well, especially by incubator projects still
learning to 'get it right'. So this I have no problem with to endorse.
Maybe not very clean, but OK.
Once a VOTE has been send out though, I personally don't like to 'reuse' that
same tag again and would prefer bumping to the next version instead.
But to be honest, there are others (within the ASF) who think differently, and
there is no absolute or formal rule on this.
Its up to the PMC (this PMC) to decide itself what rules it should follow.
You could even argue that in the VOTE thread you'd also need to specify the
exact SVN revision number for the tag VOTEd upon. And actually some projects do.
Ate
>>> Paul
>>>
>>> P.S The other builds are up at:
>>> http://people.apache.org/~psharples/wookie/staging-area/0.9.2-incubating/ if
>>> you want to check them out before I start the vote.
>>
>
Re: Reviewing release candidate
Posted by Paul Sharples <p....@bolton.ac.uk>.
On 14/02/2012 16:55, Scott Wilson wrote:
> On 14 Feb 2012, at 14:40, Paul Sharples wrote:
>
>> On 13/02/2012 18:09, Paul Sharples wrote:
>>> I'll assume lazy consensus and make the artifacts tomorrow. (unless someone finds an issue before then)
>>>
>>> Paul
>>>
>> I've found a licence issue while making the maven war artifact. As you know we make a war release using our 'ant build-release-war' task. This artifact is then usually located up at the normal apache download area. (http://www.apache.org/dist/incubator/wookie/version/binary/war) This artifact is aimed at a typical mysql/tomcat configuration and assumes that the user will deploy the war in that kind of setup. As far as I can tell, the NOTICE file is okay for this.
>>
>> However, the *new* maven war artifact we make is slightly different in that it is intended to be self contained and as such uses an embedded derby db (the maven artifact contains a 'derby-10.4.2.0.jar' file, while the other war distro does not) While reviewing the NOTICE file for this artifact I see that the reference to derby (as found in the standalone NOTICE file) is not present.
>>
>> i.e the following text...
>>
>> This software contains unmodified binary redistributions of software (Derby) developed by
>> The Apache Software Foundation (http://www.apache.org/):
>>
>> ==============================================================
>> Apache Derby
>> Copyright 2004-2008 The Apache Software Foundation
>> ==============================================================
>>
>> Portions of Derby were originally developed by
>> International Business Machines Corporation and are
>> licensed to the Apache Software Foundation under the
>> "Software Grant and Corporate Contribution License Agreement",
>> informally known as the "Derby CLA".
>> The following copyright notice(s) were affixed to portions of the code
>> with which this file is now or was at one time distributed
>> and are placed here unaltered.
>>
>> (C) Copyright 1997,2004 International Business Machines Corporation. All rights reserved.
>>
>> (C) Copyright IBM Corp. 2003.
>>
>> The portion of the functionTests under 'nist' was originally
>> developed by the National Institute of Standards and Technology (NIST),
>> an agency of the United States Department of Commerce, and adapted by
>> International Business Machines Corporation in accordance with the NIST
>> Software Acknowledgment and Redistribution document at
>> http://www.itl.nist.gov/div897/ctg/sql_form.htm
>>
>> I can quite easily add that text to the maven war artifact LICENSE before uploading to the staging area, but then the tagged '0.9.2-incubating' etc/release/war/LICENSE would be slightly different from the one found in the maven war build.
> I think you meant NOTICE? There is no additional LICENSE requirement for Derby.
Oops, Yes i did mean NOTICE, i started the email by referencing the
correct NOTICE file and then for some reason swapped to referring to it
as LICENSE, my bad.
>
> As it only affects one of the binary releases and not the source release, I would have thought we could get away with fixing this in the release artifact rather than starting another tag?
For me its a trivial change, I but wanted to check with other IPMC
members that it would be ok to do this. (I'd rather get this clear than
risk people voting -1 to the whole thing when we start the vote)
>
>
>> *If* we can't change this now, does this mean we should drop the maven WAR artifact for this release? (this doesn't affect anything else)
>> Paul
>>
>> P.S The other builds are up at: http://people.apache.org/~psharples/wookie/staging-area/0.9.2-incubating/ if you want to check them out before I start the vote.
>
Re: Reviewing release candidate
Posted by Scott Wilson <sc...@gmail.com>.
On 14 Feb 2012, at 14:40, Paul Sharples wrote:
> On 13/02/2012 18:09, Paul Sharples wrote:
>> I'll assume lazy consensus and make the artifacts tomorrow. (unless someone finds an issue before then)
>>
>> Paul
>>
>
> I've found a licence issue while making the maven war artifact. As you know we make a war release using our 'ant build-release-war' task. This artifact is then usually located up at the normal apache download area. (http://www.apache.org/dist/incubator/wookie/version/binary/war) This artifact is aimed at a typical mysql/tomcat configuration and assumes that the user will deploy the war in that kind of setup. As far as I can tell, the NOTICE file is okay for this.
>
> However, the *new* maven war artifact we make is slightly different in that it is intended to be self contained and as such uses an embedded derby db (the maven artifact contains a 'derby-10.4.2.0.jar' file, while the other war distro does not) While reviewing the NOTICE file for this artifact I see that the reference to derby (as found in the standalone NOTICE file) is not present.
>
> i.e the following text...
>
> This software contains unmodified binary redistributions of software (Derby) developed by
> The Apache Software Foundation (http://www.apache.org/):
>
> ==============================================================
> Apache Derby
> Copyright 2004-2008 The Apache Software Foundation
> ==============================================================
>
> Portions of Derby were originally developed by
> International Business Machines Corporation and are
> licensed to the Apache Software Foundation under the
> "Software Grant and Corporate Contribution License Agreement",
> informally known as the "Derby CLA".
> The following copyright notice(s) were affixed to portions of the code
> with which this file is now or was at one time distributed
> and are placed here unaltered.
>
> (C) Copyright 1997,2004 International Business Machines Corporation. All rights reserved.
>
> (C) Copyright IBM Corp. 2003.
>
> The portion of the functionTests under 'nist' was originally
> developed by the National Institute of Standards and Technology (NIST),
> an agency of the United States Department of Commerce, and adapted by
> International Business Machines Corporation in accordance with the NIST
> Software Acknowledgment and Redistribution document at
> http://www.itl.nist.gov/div897/ctg/sql_form.htm
>
> I can quite easily add that text to the maven war artifact LICENSE before uploading to the staging area, but then the tagged '0.9.2-incubating' etc/release/war/LICENSE would be slightly different from the one found in the maven war build.
I think you meant NOTICE? There is no additional LICENSE requirement for Derby.
As it only affects one of the binary releases and not the source release, I would have thought we could get away with fixing this in the release artifact rather than starting another tag?
> *If* we can't change this now, does this mean we should drop the maven WAR artifact for this release? (this doesn't affect anything else)
>
> Paul
>
> P.S The other builds are up at: http://people.apache.org/~psharples/wookie/staging-area/0.9.2-incubating/ if you want to check them out before I start the vote.
Re: Reviewing release candidate
Posted by Paul Sharples <p....@bolton.ac.uk>.
On 13/02/2012 18:09, Paul Sharples wrote:
> I'll assume lazy consensus and make the artifacts tomorrow. (unless
> someone finds an issue before then)
>
> Paul
>
I've found a licence issue while making the maven war artifact. As you
know we make a war release using our 'ant build-release-war' task. This
artifact is then usually located up at the normal apache download area.
(http://www.apache.org/dist/incubator/wookie/version/binary/war) This
artifact is aimed at a typical mysql/tomcat configuration and assumes
that the user will deploy the war in that kind of setup. As far as I
can tell, the NOTICE file is okay for this.
However, the *new* maven war artifact we make is slightly different in
that it is intended to be self contained and as such uses an embedded
derby db (the maven artifact contains a 'derby-10.4.2.0.jar' file, while
the other war distro does not) While reviewing the NOTICE file for this
artifact I see that the reference to derby (as found in the standalone
NOTICE file) is not present.
i.e the following text...
This software contains unmodified binary redistributions of software
(Derby) developed by
The Apache Software Foundation (http://www.apache.org/):
==============================================================
Apache Derby
Copyright 2004-2008 The Apache Software Foundation
==============================================================
Portions of Derby were originally developed by
International Business Machines Corporation and are
licensed to the Apache Software Foundation under the
"Software Grant and Corporate Contribution License Agreement",
informally known as the "Derby CLA".
The following copyright notice(s) were affixed to portions of the code
with which this file is now or was at one time distributed
and are placed here unaltered.
(C) Copyright 1997,2004 International Business Machines Corporation.
All rights reserved.
(C) Copyright IBM Corp. 2003.
The portion of the functionTests under 'nist' was originally
developed by the National Institute of Standards and Technology (NIST),
an agency of the United States Department of Commerce, and adapted by
International Business Machines Corporation in accordance with the NIST
Software Acknowledgment and Redistribution document at
http://www.itl.nist.gov/div897/ctg/sql_form.htm
I can quite easily add that text to the maven war artifact LICENSE
before uploading to the staging area, but then the tagged
'0.9.2-incubating' etc/release/war/LICENSE would be slightly different
from the one found in the maven war build.
*If* we can't change this now, does this mean we should drop the maven
WAR artifact for this release? (this doesn't affect anything else)
Paul
P.S The other builds are up at:
http://people.apache.org/~psharples/wookie/staging-area/0.9.2-incubating/ if
you want to check them out before I start the vote.
Re: Reviewing release candidate
Posted by Paul Sharples <p....@bolton.ac.uk>.
I'll assume lazy consensus and make the artifacts tomorrow. (unless
someone finds an issue before then)
Paul
Re: Reviewing release candidate
Posted by Ate Douma <at...@douma.nu>.
On 02/13/2012 03:11 PM, Paul Sharples wrote:
> On 13/02/2012 14:09, Scott Wilson wrote:
>> On 13 Feb 2012, at 13:39, Ate Douma wrote:
>>
>>> On 02/13/2012 01:52 PM, Paul Sharples wrote:
>>>> On 10/02/2012 12:51, Scott Wilson wrote:
>>>>> On 10 Feb 2012, at 12:44, Ate Douma wrote:
>>>>>
>>>>>> On 02/10/2012 01:18 PM, Ate Douma wrote:
>>>>>>> On 02/10/2012 11:04 AM, Paul Sharples wrote:
>>>>>>>> On 09/02/2012 11:51, Ate Douma wrote:
>>>>>>>>> I'm trying to review the current wookie trunk on LICENSE and NOTICE
>>>>>>>>> requirements for the next release.
>>>>>>>> All Jira issues are now dealt with and the Rat report now looks ok.
>>>>>>>> Do we need more time for reviewing or are we ready to cut a release?
>>>>>>> I'd like to give it one more thorough review, which I'll try to finish
>>>>>>> before
>>>>>>> end of this working day.
>>>>>> I found the following remaining issues with the NOTICE and LICENSE files in
>>>>>> standalone and war distributions:
>>>>>>
>>>>>> - both bundle openjpa, which has several/additional NOTICE and LICENSE
>>>>>> attributions which should be merged
>>>>>> - standalone in addition bundles derby which also adds to the NOTICE and
>>>>>> LICENSE requirements
>>>>>>
>>>>>> So, for both openjpa and derby, check their embedded NOTICE/LICENSE files.
>>>>> I'll get onto that now.
>>>> (a) Scott has updated both the standalone and war versions of NOTICE. Does
>>>> anything need to be added to each of the LICENSE files, or are they okay?
>>> Yes, the openjpa-all jar embedded LICENSE has several additional licenses
>>> which need to be merged with the LICENSE file for the war& standalone.
>>> For derby there are no additional LICENSE requirements, just the NOTICEs
>>> Scott already added.
>> Done
>>
>>> With respect to the added notices: I see Scott more or less 'verbatim'
>>> appended those from the openjpa-all and derby jars.
>>>
>>> As result, there now are some duplications in the resulting NOTICE, like
>>> "This product includes software developed at The Apache Software Foundation
>>> (http://www.apache.org/)" is now repeated 3x.
>>>
>>> In addition, the start section of the notice for OpenJPA (which is a ASF
>>> project) lists several other ASF projects being used. Those are not needed as
>>> we're all ASF here, and the notice at the top of the file already covers
>>> everything from the ASF itself.
>>> And it list the SERP project too in this section, but for SERP there already
>>> is a specific notice provided separately thereafter, so isn't needed in this
>>> section as well.
>>>
>>> My suggestion therefore is to remove this first section for the OpenJPA.
>> Done
>>
>>> Once the above is cleared up, AFAIK the NOTICE and LICENSE requirements
>>> should be covered.
>> Yay!
>
> Are we good to go now, or wait until tomorrow?
Looks good to me. Go!
Ate
>
> Paul
>
>>
>>> Ate
>>>
>>>>>> I also noticed the RELEASE_NOTES document hasn't been updated to include the
>>>>>> 0.9.2 issues fixed. As that list isn't complete either this task probably
>>>>>> should be done when everything else is ready.
>>>>> Yep, I'll create a task in Jira so we don't forget
>>>> (b) Now done
>>>>
>>>>>> Other than these last things, and the wrapping up of WOOKIE-314, IMO this
>>>>>> candidate is ready for release!
>>>> If point (A) above is now okay, then I think we are ready.
>>>>
>>>> Paul
>>>>
>>>>>> Regards, Ate
>>>>>>
>>>>>>> Ate
>>>>>>>
>>>>>>> p.s. I suggest someone adds the /release folder to svn:ignore.
>>>>>>> It now shows up as a svn modification.
>>>>>>>
>>>>>>>> Paul
>>>>>>>>
>>>>>>>>> First question I have is: how do I 'build' a release binary?
>>>>>>>>> From ant -p I don't see a build target which should do that.
>>>>>>>>>
>>>>>>>>> To be able to properly review what will end up in the binary release, I
>>>>>>>>> need
>>>>>>>>> to be able to build that myself, or have to wait until a candidate is
>>>>>>>>> prepared
>>>>>>>>> by others. I'd like to do it myself :)
>>>>>>>>>
>>>>>>>>> It would also be nice if a release-management kind of documentation
>>>>>>>>> could be
>>>>>>>>> published on the website, kind of similar to what we have for Rave [1].
>>>>>>>>>
>>>>>>>>> As a start I looked briefly at the root NOTICE file which raises a few
>>>>>>>>> suggestions and questions already:
>>>>>>>>>
>>>>>>>>> - Bubbles.wgt notice
>>>>>>>>> I looked the provided url up but couldn't find any license or notice
>>>>>>>>> whatsoever for inclusion/usage of this widget, and neither does the
>>>>>>>>> .wgt has
>>>>>>>>> anything embedded. Where did this *required* notice come from (note: only
>>>>>>>>> *required* notices should be added to the NOTICE file)
>>>>>>>>>
>>>>>>>>> - many/most of the other notices seems to be for MIT/BSD licensed stuff
>>>>>>>>> Those should not need notices, unless (extra) explicitly required and/or
>>>>>>>>> coming with a NOTICE (file) of their own. In general, if for these
>>>>>>>>> products
>>>>>>>>> their license (with copyright statement) is included in our LICENSE file,
>>>>>>>>> there is no need to also add a notice in the NOTICE file. AFAIK the
>>>>>>>>> /LICENSE
>>>>>>>>> file already takes care of that properly, +1 on that.
>>>>>>>>>
>>>>>>>>> In general, the NOTICE file should not be used for providing friendly
>>>>>>>>> credits.
>>>>>>>>> This file has a legal purpose only.
>>>>>>>>>
>>>>>>>>> If we want to give friendly but non-required credits, the README file
>>>>>>>>> can/should be used for that instead.
>>>>>>>>>
>>>>>>>>> Anything we add to our NOTICE (required or not) we force upon our
>>>>>>>>> downstream
>>>>>>>>> users to keep as specified by our AS 2.0 license section 4d.
>>>>>>>>> This is why more recently there is more attention for making sure we
>>>>>>>>> only put
>>>>>>>>> really required entries in the NOTICE file, to lessen the burden for our
>>>>>>>>> downstream users.
>>>>>>>>>
>>>>>>>>> Ate
>>>>>>>>>
>>
>
Re: Reviewing release candidate
Posted by Paul Sharples <p....@bolton.ac.uk>.
On 13/02/2012 14:09, Scott Wilson wrote:
> On 13 Feb 2012, at 13:39, Ate Douma wrote:
>
>> On 02/13/2012 01:52 PM, Paul Sharples wrote:
>>> On 10/02/2012 12:51, Scott Wilson wrote:
>>>> On 10 Feb 2012, at 12:44, Ate Douma wrote:
>>>>
>>>>> On 02/10/2012 01:18 PM, Ate Douma wrote:
>>>>>> On 02/10/2012 11:04 AM, Paul Sharples wrote:
>>>>>>> On 09/02/2012 11:51, Ate Douma wrote:
>>>>>>>> I'm trying to review the current wookie trunk on LICENSE and NOTICE
>>>>>>>> requirements for the next release.
>>>>>>> All Jira issues are now dealt with and the Rat report now looks ok.
>>>>>>> Do we need more time for reviewing or are we ready to cut a release?
>>>>>> I'd like to give it one more thorough review, which I'll try to finish before
>>>>>> end of this working day.
>>>>> I found the following remaining issues with the NOTICE and LICENSE files in
>>>>> standalone and war distributions:
>>>>>
>>>>> - both bundle openjpa, which has several/additional NOTICE and LICENSE
>>>>> attributions which should be merged
>>>>> - standalone in addition bundles derby which also adds to the NOTICE and
>>>>> LICENSE requirements
>>>>>
>>>>> So, for both openjpa and derby, check their embedded NOTICE/LICENSE files.
>>>> I'll get onto that now.
>>> (a) Scott has updated both the standalone and war versions of NOTICE. Does
>>> anything need to be added to each of the LICENSE files, or are they okay?
>> Yes, the openjpa-all jar embedded LICENSE has several additional licenses which need to be merged with the LICENSE file for the war& standalone.
>> For derby there are no additional LICENSE requirements, just the NOTICEs Scott already added.
> Done
>
>> With respect to the added notices: I see Scott more or less 'verbatim' appended those from the openjpa-all and derby jars.
>>
>> As result, there now are some duplications in the resulting NOTICE, like
>> "This product includes software developed at The Apache Software Foundation (http://www.apache.org/)" is now repeated 3x.
>>
>> In addition, the start section of the notice for OpenJPA (which is a ASF project) lists several other ASF projects being used. Those are not needed as we're all ASF here, and the notice at the top of the file already covers everything from the ASF itself.
>> And it list the SERP project too in this section, but for SERP there already is a specific notice provided separately thereafter, so isn't needed in this section as well.
>>
>> My suggestion therefore is to remove this first section for the OpenJPA.
> Done
>
>> Once the above is cleared up, AFAIK the NOTICE and LICENSE requirements should be covered.
> Yay!
Are we good to go now, or wait until tomorrow?
Paul
>
>> Ate
>>
>>>>> I also noticed the RELEASE_NOTES document hasn't been updated to include the
>>>>> 0.9.2 issues fixed. As that list isn't complete either this task probably
>>>>> should be done when everything else is ready.
>>>> Yep, I'll create a task in Jira so we don't forget
>>> (b) Now done
>>>
>>>>> Other than these last things, and the wrapping up of WOOKIE-314, IMO this
>>>>> candidate is ready for release!
>>> If point (A) above is now okay, then I think we are ready.
>>>
>>> Paul
>>>
>>>>> Regards, Ate
>>>>>
>>>>>> Ate
>>>>>>
>>>>>> p.s. I suggest someone adds the /release folder to svn:ignore.
>>>>>> It now shows up as a svn modification.
>>>>>>
>>>>>>> Paul
>>>>>>>
>>>>>>>> First question I have is: how do I 'build' a release binary?
>>>>>>>> From ant -p I don't see a build target which should do that.
>>>>>>>>
>>>>>>>> To be able to properly review what will end up in the binary release, I need
>>>>>>>> to be able to build that myself, or have to wait until a candidate is
>>>>>>>> prepared
>>>>>>>> by others. I'd like to do it myself :)
>>>>>>>>
>>>>>>>> It would also be nice if a release-management kind of documentation could be
>>>>>>>> published on the website, kind of similar to what we have for Rave [1].
>>>>>>>>
>>>>>>>> As a start I looked briefly at the root NOTICE file which raises a few
>>>>>>>> suggestions and questions already:
>>>>>>>>
>>>>>>>> - Bubbles.wgt notice
>>>>>>>> I looked the provided url up but couldn't find any license or notice
>>>>>>>> whatsoever for inclusion/usage of this widget, and neither does the .wgt has
>>>>>>>> anything embedded. Where did this *required* notice come from (note: only
>>>>>>>> *required* notices should be added to the NOTICE file)
>>>>>>>>
>>>>>>>> - many/most of the other notices seems to be for MIT/BSD licensed stuff
>>>>>>>> Those should not need notices, unless (extra) explicitly required and/or
>>>>>>>> coming with a NOTICE (file) of their own. In general, if for these products
>>>>>>>> their license (with copyright statement) is included in our LICENSE file,
>>>>>>>> there is no need to also add a notice in the NOTICE file. AFAIK the /LICENSE
>>>>>>>> file already takes care of that properly, +1 on that.
>>>>>>>>
>>>>>>>> In general, the NOTICE file should not be used for providing friendly
>>>>>>>> credits.
>>>>>>>> This file has a legal purpose only.
>>>>>>>>
>>>>>>>> If we want to give friendly but non-required credits, the README file
>>>>>>>> can/should be used for that instead.
>>>>>>>>
>>>>>>>> Anything we add to our NOTICE (required or not) we force upon our downstream
>>>>>>>> users to keep as specified by our AS 2.0 license section 4d.
>>>>>>>> This is why more recently there is more attention for making sure we only put
>>>>>>>> really required entries in the NOTICE file, to lessen the burden for our
>>>>>>>> downstream users.
>>>>>>>>
>>>>>>>> Ate
>>>>>>>>
>
Re: Reviewing release candidate
Posted by Scott Wilson <sc...@gmail.com>.
On 13 Feb 2012, at 13:39, Ate Douma wrote:
> On 02/13/2012 01:52 PM, Paul Sharples wrote:
>> On 10/02/2012 12:51, Scott Wilson wrote:
>>> On 10 Feb 2012, at 12:44, Ate Douma wrote:
>>>
>>>> On 02/10/2012 01:18 PM, Ate Douma wrote:
>>>>> On 02/10/2012 11:04 AM, Paul Sharples wrote:
>>>>>> On 09/02/2012 11:51, Ate Douma wrote:
>>>>>>> I'm trying to review the current wookie trunk on LICENSE and NOTICE
>>>>>>> requirements for the next release.
>>>>>> All Jira issues are now dealt with and the Rat report now looks ok.
>>>>>> Do we need more time for reviewing or are we ready to cut a release?
>>>>> I'd like to give it one more thorough review, which I'll try to finish before
>>>>> end of this working day.
>>>> I found the following remaining issues with the NOTICE and LICENSE files in
>>>> standalone and war distributions:
>>>>
>>>> - both bundle openjpa, which has several/additional NOTICE and LICENSE
>>>> attributions which should be merged
>>>> - standalone in addition bundles derby which also adds to the NOTICE and
>>>> LICENSE requirements
>>>>
>>>> So, for both openjpa and derby, check their embedded NOTICE/LICENSE files.
>>> I'll get onto that now.
>>
>> (a) Scott has updated both the standalone and war versions of NOTICE. Does
>> anything need to be added to each of the LICENSE files, or are they okay?
>
> Yes, the openjpa-all jar embedded LICENSE has several additional licenses which need to be merged with the LICENSE file for the war & standalone.
> For derby there are no additional LICENSE requirements, just the NOTICEs Scott already added.
Done
>
> With respect to the added notices: I see Scott more or less 'verbatim' appended those from the openjpa-all and derby jars.
>
> As result, there now are some duplications in the resulting NOTICE, like
> "This product includes software developed at The Apache Software Foundation (http://www.apache.org/)" is now repeated 3x.
>
> In addition, the start section of the notice for OpenJPA (which is a ASF project) lists several other ASF projects being used. Those are not needed as we're all ASF here, and the notice at the top of the file already covers everything from the ASF itself.
> And it list the SERP project too in this section, but for SERP there already is a specific notice provided separately thereafter, so isn't needed in this section as well.
>
> My suggestion therefore is to remove this first section for the OpenJPA.
Done
>
> Once the above is cleared up, AFAIK the NOTICE and LICENSE requirements should be covered.
Yay!
>
> Ate
>
>>
>>>
>>>> I also noticed the RELEASE_NOTES document hasn't been updated to include the
>>>> 0.9.2 issues fixed. As that list isn't complete either this task probably
>>>> should be done when everything else is ready.
>>> Yep, I'll create a task in Jira so we don't forget
>>
>> (b) Now done
>>
>>>> Other than these last things, and the wrapping up of WOOKIE-314, IMO this
>>>> candidate is ready for release!
>>
>> If point (A) above is now okay, then I think we are ready.
>>
>> Paul
>>
>>>>
>>>> Regards, Ate
>>>>
>>>>> Ate
>>>>>
>>>>> p.s. I suggest someone adds the /release folder to svn:ignore.
>>>>> It now shows up as a svn modification.
>>>>>
>>>>>> Paul
>>>>>>
>>>>>>> First question I have is: how do I 'build' a release binary?
>>>>>>> From ant -p I don't see a build target which should do that.
>>>>>>>
>>>>>>> To be able to properly review what will end up in the binary release, I need
>>>>>>> to be able to build that myself, or have to wait until a candidate is
>>>>>>> prepared
>>>>>>> by others. I'd like to do it myself :)
>>>>>>>
>>>>>>> It would also be nice if a release-management kind of documentation could be
>>>>>>> published on the website, kind of similar to what we have for Rave [1].
>>>>>>>
>>>>>>> As a start I looked briefly at the root NOTICE file which raises a few
>>>>>>> suggestions and questions already:
>>>>>>>
>>>>>>> - Bubbles.wgt notice
>>>>>>> I looked the provided url up but couldn't find any license or notice
>>>>>>> whatsoever for inclusion/usage of this widget, and neither does the .wgt has
>>>>>>> anything embedded. Where did this *required* notice come from (note: only
>>>>>>> *required* notices should be added to the NOTICE file)
>>>>>>>
>>>>>>> - many/most of the other notices seems to be for MIT/BSD licensed stuff
>>>>>>> Those should not need notices, unless (extra) explicitly required and/or
>>>>>>> coming with a NOTICE (file) of their own. In general, if for these products
>>>>>>> their license (with copyright statement) is included in our LICENSE file,
>>>>>>> there is no need to also add a notice in the NOTICE file. AFAIK the /LICENSE
>>>>>>> file already takes care of that properly, +1 on that.
>>>>>>>
>>>>>>> In general, the NOTICE file should not be used for providing friendly
>>>>>>> credits.
>>>>>>> This file has a legal purpose only.
>>>>>>>
>>>>>>> If we want to give friendly but non-required credits, the README file
>>>>>>> can/should be used for that instead.
>>>>>>>
>>>>>>> Anything we add to our NOTICE (required or not) we force upon our downstream
>>>>>>> users to keep as specified by our AS 2.0 license section 4d.
>>>>>>> This is why more recently there is more attention for making sure we only put
>>>>>>> really required entries in the NOTICE file, to lessen the burden for our
>>>>>>> downstream users.
>>>>>>>
>>>>>>> Ate
>>>>>>>
>>>
>>
>
Re: Reviewing release candidate
Posted by Ate Douma <at...@douma.nu>.
On 02/13/2012 01:52 PM, Paul Sharples wrote:
> On 10/02/2012 12:51, Scott Wilson wrote:
>> On 10 Feb 2012, at 12:44, Ate Douma wrote:
>>
>>> On 02/10/2012 01:18 PM, Ate Douma wrote:
>>>> On 02/10/2012 11:04 AM, Paul Sharples wrote:
>>>>> On 09/02/2012 11:51, Ate Douma wrote:
>>>>>> I'm trying to review the current wookie trunk on LICENSE and NOTICE
>>>>>> requirements for the next release.
>>>>> All Jira issues are now dealt with and the Rat report now looks ok.
>>>>> Do we need more time for reviewing or are we ready to cut a release?
>>>> I'd like to give it one more thorough review, which I'll try to finish before
>>>> end of this working day.
>>> I found the following remaining issues with the NOTICE and LICENSE files in
>>> standalone and war distributions:
>>>
>>> - both bundle openjpa, which has several/additional NOTICE and LICENSE
>>> attributions which should be merged
>>> - standalone in addition bundles derby which also adds to the NOTICE and
>>> LICENSE requirements
>>>
>>> So, for both openjpa and derby, check their embedded NOTICE/LICENSE files.
>> I'll get onto that now.
>
> (a) Scott has updated both the standalone and war versions of NOTICE. Does
> anything need to be added to each of the LICENSE files, or are they okay?
Yes, the openjpa-all jar embedded LICENSE has several additional licenses which
need to be merged with the LICENSE file for the war & standalone.
For derby there are no additional LICENSE requirements, just the NOTICEs Scott
already added.
With respect to the added notices: I see Scott more or less 'verbatim' appended
those from the openjpa-all and derby jars.
As result, there now are some duplications in the resulting NOTICE, like
"This product includes software developed at The Apache Software Foundation
(http://www.apache.org/)" is now repeated 3x.
In addition, the start section of the notice for OpenJPA (which is a ASF
project) lists several other ASF projects being used. Those are not needed as
we're all ASF here, and the notice at the top of the file already covers
everything from the ASF itself.
And it list the SERP project too in this section, but for SERP there already is
a specific notice provided separately thereafter, so isn't needed in this
section as well.
My suggestion therefore is to remove this first section for the OpenJPA.
Once the above is cleared up, AFAIK the NOTICE and LICENSE requirements should
be covered.
Ate
>
>>
>>> I also noticed the RELEASE_NOTES document hasn't been updated to include the
>>> 0.9.2 issues fixed. As that list isn't complete either this task probably
>>> should be done when everything else is ready.
>> Yep, I'll create a task in Jira so we don't forget
>
> (b) Now done
>
>>> Other than these last things, and the wrapping up of WOOKIE-314, IMO this
>>> candidate is ready for release!
>
> If point (A) above is now okay, then I think we are ready.
>
> Paul
>
>>>
>>> Regards, Ate
>>>
>>>> Ate
>>>>
>>>> p.s. I suggest someone adds the /release folder to svn:ignore.
>>>> It now shows up as a svn modification.
>>>>
>>>>> Paul
>>>>>
>>>>>> First question I have is: how do I 'build' a release binary?
>>>>>> From ant -p I don't see a build target which should do that.
>>>>>>
>>>>>> To be able to properly review what will end up in the binary release, I need
>>>>>> to be able to build that myself, or have to wait until a candidate is
>>>>>> prepared
>>>>>> by others. I'd like to do it myself :)
>>>>>>
>>>>>> It would also be nice if a release-management kind of documentation could be
>>>>>> published on the website, kind of similar to what we have for Rave [1].
>>>>>>
>>>>>> As a start I looked briefly at the root NOTICE file which raises a few
>>>>>> suggestions and questions already:
>>>>>>
>>>>>> - Bubbles.wgt notice
>>>>>> I looked the provided url up but couldn't find any license or notice
>>>>>> whatsoever for inclusion/usage of this widget, and neither does the .wgt has
>>>>>> anything embedded. Where did this *required* notice come from (note: only
>>>>>> *required* notices should be added to the NOTICE file)
>>>>>>
>>>>>> - many/most of the other notices seems to be for MIT/BSD licensed stuff
>>>>>> Those should not need notices, unless (extra) explicitly required and/or
>>>>>> coming with a NOTICE (file) of their own. In general, if for these products
>>>>>> their license (with copyright statement) is included in our LICENSE file,
>>>>>> there is no need to also add a notice in the NOTICE file. AFAIK the /LICENSE
>>>>>> file already takes care of that properly, +1 on that.
>>>>>>
>>>>>> In general, the NOTICE file should not be used for providing friendly
>>>>>> credits.
>>>>>> This file has a legal purpose only.
>>>>>>
>>>>>> If we want to give friendly but non-required credits, the README file
>>>>>> can/should be used for that instead.
>>>>>>
>>>>>> Anything we add to our NOTICE (required or not) we force upon our downstream
>>>>>> users to keep as specified by our AS 2.0 license section 4d.
>>>>>> This is why more recently there is more attention for making sure we only put
>>>>>> really required entries in the NOTICE file, to lessen the burden for our
>>>>>> downstream users.
>>>>>>
>>>>>> Ate
>>>>>>
>>
>
Re: Reviewing release candidate
Posted by Paul Sharples <p....@bolton.ac.uk>.
On 10/02/2012 12:51, Scott Wilson wrote:
> On 10 Feb 2012, at 12:44, Ate Douma wrote:
>
>> On 02/10/2012 01:18 PM, Ate Douma wrote:
>>> On 02/10/2012 11:04 AM, Paul Sharples wrote:
>>>> On 09/02/2012 11:51, Ate Douma wrote:
>>>>> I'm trying to review the current wookie trunk on LICENSE and NOTICE
>>>>> requirements for the next release.
>>>> All Jira issues are now dealt with and the Rat report now looks ok.
>>>> Do we need more time for reviewing or are we ready to cut a release?
>>> I'd like to give it one more thorough review, which I'll try to finish before
>>> end of this working day.
>> I found the following remaining issues with the NOTICE and LICENSE files in standalone and war distributions:
>>
>> - both bundle openjpa, which has several/additional NOTICE and LICENSE attributions which should be merged
>> - standalone in addition bundles derby which also adds to the NOTICE and LICENSE requirements
>>
>> So, for both openjpa and derby, check their embedded NOTICE/LICENSE files.
> I'll get onto that now.
(a) Scott has updated both the standalone and war versions of NOTICE.
Does anything need to be added to each of the LICENSE files, or are they
okay?
>
>> I also noticed the RELEASE_NOTES document hasn't been updated to include the 0.9.2 issues fixed. As that list isn't complete either this task probably should be done when everything else is ready.
> Yep, I'll create a task in Jira so we don't forget
(b) Now done
>> Other than these last things, and the wrapping up of WOOKIE-314, IMO this candidate is ready for release!
If point (A) above is now okay, then I think we are ready.
Paul
>>
>> Regards, Ate
>>
>>> Ate
>>>
>>> p.s. I suggest someone adds the /release folder to svn:ignore.
>>> It now shows up as a svn modification.
>>>
>>>> Paul
>>>>
>>>>> First question I have is: how do I 'build' a release binary?
>>>>> From ant -p I don't see a build target which should do that.
>>>>>
>>>>> To be able to properly review what will end up in the binary release, I need
>>>>> to be able to build that myself, or have to wait until a candidate is prepared
>>>>> by others. I'd like to do it myself :)
>>>>>
>>>>> It would also be nice if a release-management kind of documentation could be
>>>>> published on the website, kind of similar to what we have for Rave [1].
>>>>>
>>>>> As a start I looked briefly at the root NOTICE file which raises a few
>>>>> suggestions and questions already:
>>>>>
>>>>> - Bubbles.wgt notice
>>>>> I looked the provided url up but couldn't find any license or notice
>>>>> whatsoever for inclusion/usage of this widget, and neither does the .wgt has
>>>>> anything embedded. Where did this *required* notice come from (note: only
>>>>> *required* notices should be added to the NOTICE file)
>>>>>
>>>>> - many/most of the other notices seems to be for MIT/BSD licensed stuff
>>>>> Those should not need notices, unless (extra) explicitly required and/or
>>>>> coming with a NOTICE (file) of their own. In general, if for these products
>>>>> their license (with copyright statement) is included in our LICENSE file,
>>>>> there is no need to also add a notice in the NOTICE file. AFAIK the /LICENSE
>>>>> file already takes care of that properly, +1 on that.
>>>>>
>>>>> In general, the NOTICE file should not be used for providing friendly credits.
>>>>> This file has a legal purpose only.
>>>>>
>>>>> If we want to give friendly but non-required credits, the README file
>>>>> can/should be used for that instead.
>>>>>
>>>>> Anything we add to our NOTICE (required or not) we force upon our downstream
>>>>> users to keep as specified by our AS 2.0 license section 4d.
>>>>> This is why more recently there is more attention for making sure we only put
>>>>> really required entries in the NOTICE file, to lessen the burden for our
>>>>> downstream users.
>>>>>
>>>>> Ate
>>>>>
>
Re: Reviewing release candidate
Posted by Scott Wilson <sc...@gmail.com>.
On 10 Feb 2012, at 12:44, Ate Douma wrote:
> On 02/10/2012 01:18 PM, Ate Douma wrote:
>> On 02/10/2012 11:04 AM, Paul Sharples wrote:
>>> On 09/02/2012 11:51, Ate Douma wrote:
>>>> I'm trying to review the current wookie trunk on LICENSE and NOTICE
>>>> requirements for the next release.
>>>
>>> All Jira issues are now dealt with and the Rat report now looks ok.
>>> Do we need more time for reviewing or are we ready to cut a release?
>>
>> I'd like to give it one more thorough review, which I'll try to finish before
>> end of this working day.
>
> I found the following remaining issues with the NOTICE and LICENSE files in standalone and war distributions:
>
> - both bundle openjpa, which has several/additional NOTICE and LICENSE attributions which should be merged
> - standalone in addition bundles derby which also adds to the NOTICE and LICENSE requirements
>
> So, for both openjpa and derby, check their embedded NOTICE/LICENSE files.
I'll get onto that now.
>
> I also noticed the RELEASE_NOTES document hasn't been updated to include the 0.9.2 issues fixed. As that list isn't complete either this task probably should be done when everything else is ready.
Yep, I'll create a task in Jira so we don't forget
>
> Other than these last things, and the wrapping up of WOOKIE-314, IMO this candidate is ready for release!
>
> Regards, Ate
>
>>
>> Ate
>>
>> p.s. I suggest someone adds the /release folder to svn:ignore.
>> It now shows up as a svn modification.
>>
>>>
>>> Paul
>>>
>>>>
>>>> First question I have is: how do I 'build' a release binary?
>>>> From ant -p I don't see a build target which should do that.
>>>>
>>>> To be able to properly review what will end up in the binary release, I need
>>>> to be able to build that myself, or have to wait until a candidate is prepared
>>>> by others. I'd like to do it myself :)
>>>>
>>>> It would also be nice if a release-management kind of documentation could be
>>>> published on the website, kind of similar to what we have for Rave [1].
>>>>
>>>> As a start I looked briefly at the root NOTICE file which raises a few
>>>> suggestions and questions already:
>>>>
>>>> - Bubbles.wgt notice
>>>> I looked the provided url up but couldn't find any license or notice
>>>> whatsoever for inclusion/usage of this widget, and neither does the .wgt has
>>>> anything embedded. Where did this *required* notice come from (note: only
>>>> *required* notices should be added to the NOTICE file)
>>>>
>>>> - many/most of the other notices seems to be for MIT/BSD licensed stuff
>>>> Those should not need notices, unless (extra) explicitly required and/or
>>>> coming with a NOTICE (file) of their own. In general, if for these products
>>>> their license (with copyright statement) is included in our LICENSE file,
>>>> there is no need to also add a notice in the NOTICE file. AFAIK the /LICENSE
>>>> file already takes care of that properly, +1 on that.
>>>>
>>>> In general, the NOTICE file should not be used for providing friendly credits.
>>>> This file has a legal purpose only.
>>>>
>>>> If we want to give friendly but non-required credits, the README file
>>>> can/should be used for that instead.
>>>>
>>>> Anything we add to our NOTICE (required or not) we force upon our downstream
>>>> users to keep as specified by our AS 2.0 license section 4d.
>>>> This is why more recently there is more attention for making sure we only put
>>>> really required entries in the NOTICE file, to lessen the burden for our
>>>> downstream users.
>>>>
>>>> Ate
>>>>
>>>
>>
>
Re: Reviewing release candidate
Posted by Ate Douma <at...@douma.nu>.
On 02/10/2012 01:18 PM, Ate Douma wrote:
> On 02/10/2012 11:04 AM, Paul Sharples wrote:
>> On 09/02/2012 11:51, Ate Douma wrote:
>>> I'm trying to review the current wookie trunk on LICENSE and NOTICE
>>> requirements for the next release.
>>
>> All Jira issues are now dealt with and the Rat report now looks ok.
>> Do we need more time for reviewing or are we ready to cut a release?
>
> I'd like to give it one more thorough review, which I'll try to finish before
> end of this working day.
I found the following remaining issues with the NOTICE and LICENSE files in
standalone and war distributions:
- both bundle openjpa, which has several/additional NOTICE and LICENSE
attributions which should be merged
- standalone in addition bundles derby which also adds to the NOTICE and LICENSE
requirements
So, for both openjpa and derby, check their embedded NOTICE/LICENSE files.
I also noticed the RELEASE_NOTES document hasn't been updated to include the
0.9.2 issues fixed. As that list isn't complete either this task probably should
be done when everything else is ready.
Other than these last things, and the wrapping up of WOOKIE-314, IMO this
candidate is ready for release!
Regards, Ate
>
> Ate
>
> p.s. I suggest someone adds the /release folder to svn:ignore.
> It now shows up as a svn modification.
>
>>
>> Paul
>>
>>>
>>> First question I have is: how do I 'build' a release binary?
>>> From ant -p I don't see a build target which should do that.
>>>
>>> To be able to properly review what will end up in the binary release, I need
>>> to be able to build that myself, or have to wait until a candidate is prepared
>>> by others. I'd like to do it myself :)
>>>
>>> It would also be nice if a release-management kind of documentation could be
>>> published on the website, kind of similar to what we have for Rave [1].
>>>
>>> As a start I looked briefly at the root NOTICE file which raises a few
>>> suggestions and questions already:
>>>
>>> - Bubbles.wgt notice
>>> I looked the provided url up but couldn't find any license or notice
>>> whatsoever for inclusion/usage of this widget, and neither does the .wgt has
>>> anything embedded. Where did this *required* notice come from (note: only
>>> *required* notices should be added to the NOTICE file)
>>>
>>> - many/most of the other notices seems to be for MIT/BSD licensed stuff
>>> Those should not need notices, unless (extra) explicitly required and/or
>>> coming with a NOTICE (file) of their own. In general, if for these products
>>> their license (with copyright statement) is included in our LICENSE file,
>>> there is no need to also add a notice in the NOTICE file. AFAIK the /LICENSE
>>> file already takes care of that properly, +1 on that.
>>>
>>> In general, the NOTICE file should not be used for providing friendly credits.
>>> This file has a legal purpose only.
>>>
>>> If we want to give friendly but non-required credits, the README file
>>> can/should be used for that instead.
>>>
>>> Anything we add to our NOTICE (required or not) we force upon our downstream
>>> users to keep as specified by our AS 2.0 license section 4d.
>>> This is why more recently there is more attention for making sure we only put
>>> really required entries in the NOTICE file, to lessen the burden for our
>>> downstream users.
>>>
>>> Ate
>>>
>>
>
Re: Reviewing release candidate
Posted by Ate Douma <at...@douma.nu>.
On 02/10/2012 11:04 AM, Paul Sharples wrote:
> On 09/02/2012 11:51, Ate Douma wrote:
>> I'm trying to review the current wookie trunk on LICENSE and NOTICE
>> requirements for the next release.
>
> All Jira issues are now dealt with and the Rat report now looks ok.
> Do we need more time for reviewing or are we ready to cut a release?
I'd like to give it one more thorough review, which I'll try to finish before
end of this working day.
Ate
p.s. I suggest someone adds the /release folder to svn:ignore.
It now shows up as a svn modification.
>
> Paul
>
>>
>> First question I have is: how do I 'build' a release binary?
>> From ant -p I don't see a build target which should do that.
>>
>> To be able to properly review what will end up in the binary release, I need
>> to be able to build that myself, or have to wait until a candidate is prepared
>> by others. I'd like to do it myself :)
>>
>> It would also be nice if a release-management kind of documentation could be
>> published on the website, kind of similar to what we have for Rave [1].
>>
>> As a start I looked briefly at the root NOTICE file which raises a few
>> suggestions and questions already:
>>
>> - Bubbles.wgt notice
>> I looked the provided url up but couldn't find any license or notice
>> whatsoever for inclusion/usage of this widget, and neither does the .wgt has
>> anything embedded. Where did this *required* notice come from (note: only
>> *required* notices should be added to the NOTICE file)
>>
>> - many/most of the other notices seems to be for MIT/BSD licensed stuff
>> Those should not need notices, unless (extra) explicitly required and/or
>> coming with a NOTICE (file) of their own. In general, if for these products
>> their license (with copyright statement) is included in our LICENSE file,
>> there is no need to also add a notice in the NOTICE file. AFAIK the /LICENSE
>> file already takes care of that properly, +1 on that.
>>
>> In general, the NOTICE file should not be used for providing friendly credits.
>> This file has a legal purpose only.
>>
>> If we want to give friendly but non-required credits, the README file
>> can/should be used for that instead.
>>
>> Anything we add to our NOTICE (required or not) we force upon our downstream
>> users to keep as specified by our AS 2.0 license section 4d.
>> This is why more recently there is more attention for making sure we only put
>> really required entries in the NOTICE file, to lessen the burden for our
>> downstream users.
>>
>> Ate
>>
>
Re: Reviewing release candidate
Posted by Paul Sharples <p....@bolton.ac.uk>.
On 09/02/2012 11:51, Ate Douma wrote:
> I'm trying to review the current wookie trunk on LICENSE and NOTICE
> requirements for the next release.
All Jira issues are now dealt with and the Rat report now looks ok.
Do we need more time for reviewing or are we ready to cut a release?
Paul
>
> First question I have is: how do I 'build' a release binary?
> From ant -p I don't see a build target which should do that.
>
> To be able to properly review what will end up in the binary release,
> I need to be able to build that myself, or have to wait until a
> candidate is prepared by others. I'd like to do it myself :)
>
> It would also be nice if a release-management kind of documentation
> could be published on the website, kind of similar to what we have for
> Rave [1].
>
> As a start I looked briefly at the root NOTICE file which raises a few
> suggestions and questions already:
>
> - Bubbles.wgt notice
> I looked the provided url up but couldn't find any license or notice
> whatsoever for inclusion/usage of this widget, and neither does the
> .wgt has anything embedded. Where did this *required* notice come from
> (note: only *required* notices should be added to the NOTICE file)
>
> - many/most of the other notices seems to be for MIT/BSD licensed stuff
> Those should not need notices, unless (extra) explicitly required
> and/or coming with a NOTICE (file) of their own. In general, if for
> these products their license (with copyright statement) is included in
> our LICENSE file, there is no need to also add a notice in the NOTICE
> file. AFAIK the /LICENSE file already takes care of that properly, +1
> on that.
>
> In general, the NOTICE file should not be used for providing friendly
> credits. This file has a legal purpose only.
>
> If we want to give friendly but non-required credits, the README file
> can/should be used for that instead.
>
> Anything we add to our NOTICE (required or not) we force upon our
> downstream users to keep as specified by our AS 2.0 license section 4d.
> This is why more recently there is more attention for making sure we
> only put really required entries in the NOTICE file, to lessen the
> burden for our downstream users.
>
> Ate
>