You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wookie.apache.org by Scott Wilson <sc...@gmail.com> on 2010/10/26 18:46:50 UTC
Release progress
Hi everyone,
I've been through the source code and licenses, and updated our existing license documentation, and created the LICENSE and NOTICE files. I'm satisfied we're in good shape in terms of the License Audit and Legal Audit part of the release process [1].
I've also done work on the documentation; it still needs testing against the release but is in a reasonable state now.
As far as the tracker goes, there is now only one issue outstanding issue [2].
I can't remember offhand the deadline we set for ourselves - are we still on target? What's next?
Cheers,
S
[1] https://cwiki.apache.org/confluence/display/WOOKIE/Wookie+First+Release
[2] https://issues.apache.org/jira/browse/WOOKIE-44
Re: Release progress
Posted by Ross Gardler <rg...@apache.org>.
On 26/10/2010 17:46, Scott Wilson wrote:
> Hi everyone,
>
> I've been through the source code and licenses, and updated our
> existing license documentation, and created the LICENSE and NOTICE
> files. I'm satisfied we're in good shape in terms of the License
> Audit and Legal Audit part of the release process [1].
>
> I've also done work on the documentation; it still needs testing
> against the release but is in a reasonable state now.
Excellent.
For my part I have tested the current SVN head fairly rigourously. i
have not yet done any reviews of licences etc. since it has been clear
you were working on them.
> I can't remember offhand the deadline we set for ourselves - are we
> still on target? What's next?
Sander is presenting Wookie at ApacheCon on Wed 3rd Nov. We will miss
this for a full release but we can still have a release tarball
available for testing. Just in case anyone at ApacheCon wants to have a go.
It's not the end of the world if we don't make that deadline, it would
just be nice to be able to answer the question "what is the current
development status" with "there is a candidate release in testing right
now - want to help?" rather than "we will have a release out very soon."
Ross
Re: Release progress
Posted by Raido Kuli <ra...@gmail.com>.
Hi,
My key here: http://pgp.mit.edu:11371/pks/lookup?search=Raido+Kuli&op=index
--
Raido
On 28.10.2010, at 20:41, Paul Sharples wrote:
> On 28/10/2010 15:26, Scott Wilson wrote:
>> On 28 Oct 2010, at 10:19, Kris Popat wrote:
>>
>>
>>> Hi
>>>
>>> On 26 Oct 2010, at 17:46, Scott Wilson wrote:
>>>
>>>
>>>> Hi everyone,
>>>>
>>>> I've been through the source code and licenses, and updated our existing license documentation, and created the LICENSE and NOTICE files. I'm satisfied we're in good shape in terms of the License Audit and Legal Audit part of the release process [1].
>>>>
>>>> I've also done work on the documentation; it still needs testing against the release but is in a reasonable state now.
>>>>
>>>> As far as the tracker goes, there is now only one issue outstanding issue [2].
>>>>
>>>> I can't remember offhand the deadline we set for ourselves - are we still on target? What's next?
>>>>
>>> Looks like we need to do testing and verifying of issues.
>>>
>>> After this I think we should create the release branch, or do people think we should do it now?
>>>
>> I guess if verifying the issues shows up something that needs an urgent fix it would be a pain to have to sync branch and trunk. Also we may end up committing more unit tests in the process. Lets just get the issues verified as soon as we can!
>>
>>
>>> I've updated the section on signatures on the release doc - included here.
>>>
>>>
>>> The committers for the project need to provide public keys for the release, each person who submits a key needs to keep the private key safe. These will be included with the release in a KEYS file. The process of creating a key pair should be consistent across the committers. Apache recommend using GNU Privacy Guard to generate keys and sign the artifacts.
>>>
>> My public key is listed here:
>>
>> http://pgp.mit.edu:11371/pks/lookup?search=Scott+Wilson+%3Cscott.bradley.wilson%40gmail.com%3E+&op=index
>>
>>
> Mine is here...
>
> http://pgp.mit.edu:11371/pks/lookup?search=paul+sharples&op=index
>>> Committers without a code signing key should generate one - RSA 4096 bits
>>>
>>> If committers have a DSA or RSA key of less than 2048 bits then a new one should be generated for signing releases, again using RSA 4096 bit.
>>>
>>> For committers who already have an RSA key of 2048 bits or more some configuration of their client to avoid weaknesses are required. Instructions on how to do this can be found here.
>>>
>>>
>>>
>>> Kris
>>>
>>
>
Re: Release progress
Posted by Paul Sharples <p....@bolton.ac.uk>.
On 28/10/2010 15:26, Scott Wilson wrote:
> On 28 Oct 2010, at 10:19, Kris Popat wrote:
>
>
>> Hi
>>
>> On 26 Oct 2010, at 17:46, Scott Wilson wrote:
>>
>>
>>> Hi everyone,
>>>
>>> I've been through the source code and licenses, and updated our existing license documentation, and created the LICENSE and NOTICE files. I'm satisfied we're in good shape in terms of the License Audit and Legal Audit part of the release process [1].
>>>
>>> I've also done work on the documentation; it still needs testing against the release but is in a reasonable state now.
>>>
>>> As far as the tracker goes, there is now only one issue outstanding issue [2].
>>>
>>> I can't remember offhand the deadline we set for ourselves - are we still on target? What's next?
>>>
>> Looks like we need to do testing and verifying of issues.
>>
>> After this I think we should create the release branch, or do people think we should do it now?
>>
> I guess if verifying the issues shows up something that needs an urgent fix it would be a pain to have to sync branch and trunk. Also we may end up committing more unit tests in the process. Lets just get the issues verified as soon as we can!
>
>
>> I've updated the section on signatures on the release doc - included here.
>>
>>
>> The committers for the project need to provide public keys for the release, each person who submits a key needs to keep the private key safe. These will be included with the release in a KEYS file. The process of creating a key pair should be consistent across the committers. Apache recommend using GNU Privacy Guard to generate keys and sign the artifacts.
>>
> My public key is listed here:
>
> http://pgp.mit.edu:11371/pks/lookup?search=Scott+Wilson+%3Cscott.bradley.wilson%40gmail.com%3E+&op=index
>
>
Mine is here...
http://pgp.mit.edu:11371/pks/lookup?search=paul+sharples&op=index
>> Committers without a code signing key should generate one - RSA 4096 bits
>>
>> If committers have a DSA or RSA key of less than 2048 bits then a new one should be generated for signing releases, again using RSA 4096 bit.
>>
>> For committers who already have an RSA key of 2048 bits or more some configuration of their client to avoid weaknesses are required. Instructions on how to do this can be found here.
>>
>>
>>
>> Kris
>>
>
Re: Release progress
Posted by Scott Wilson <sc...@gmail.com>.
On 28 Oct 2010, at 10:19, Kris Popat wrote:
> Hi
>
> On 26 Oct 2010, at 17:46, Scott Wilson wrote:
>
>> Hi everyone,
>>
>> I've been through the source code and licenses, and updated our existing license documentation, and created the LICENSE and NOTICE files. I'm satisfied we're in good shape in terms of the License Audit and Legal Audit part of the release process [1].
>>
>> I've also done work on the documentation; it still needs testing against the release but is in a reasonable state now.
>>
>> As far as the tracker goes, there is now only one issue outstanding issue [2].
>>
>> I can't remember offhand the deadline we set for ourselves - are we still on target? What's next?
>
> Looks like we need to do testing and verifying of issues.
>
> After this I think we should create the release branch, or do people think we should do it now?
I guess if verifying the issues shows up something that needs an urgent fix it would be a pain to have to sync branch and trunk. Also we may end up committing more unit tests in the process. Lets just get the issues verified as soon as we can!
>
> I've updated the section on signatures on the release doc - included here.
>
>
> The committers for the project need to provide public keys for the release, each person who submits a key needs to keep the private key safe. These will be included with the release in a KEYS file. The process of creating a key pair should be consistent across the committers. Apache recommend using GNU Privacy Guard to generate keys and sign the artifacts.
My public key is listed here:
http://pgp.mit.edu:11371/pks/lookup?search=Scott+Wilson+%3Cscott.bradley.wilson%40gmail.com%3E+&op=index
> Committers without a code signing key should generate one - RSA 4096 bits
>
> If committers have a DSA or RSA key of less than 2048 bits then a new one should be generated for signing releases, again using RSA 4096 bit.
>
> For committers who already have an RSA key of 2048 bits or more some configuration of their client to avoid weaknesses are required. Instructions on how to do this can be found here.
>
>
>
> Kris
Re: Release progress
Posted by Kris Popat <kj...@gmail.com>.
Hi
On 26 Oct 2010, at 17:46, Scott Wilson wrote:
> Hi everyone,
>
> I've been through the source code and licenses, and updated our
> existing license documentation, and created the LICENSE and NOTICE
> files. I'm satisfied we're in good shape in terms of the License
> Audit and Legal Audit part of the release process [1].
>
> I've also done work on the documentation; it still needs testing
> against the release but is in a reasonable state now.
>
> As far as the tracker goes, there is now only one issue outstanding
> issue [2].
>
> I can't remember offhand the deadline we set for ourselves - are we
> still on target? What's next?
Looks like we need to do testing and verifying of issues.
After this I think we should create the release branch, or do people
think we should do it now?
I've updated the section on signatures on the release doc - included
here.
The committers for the project need to provide public keys for the
release, each person who submits a key needs to keep the private key
safe. These will be included with the release in a KEYS file. The
process of creating a key pair should be consistent across the
committers. Apache recommend using GNU Privacy Guard to generate keys
and sign the artifacts.
Committers without a code signing key should generate one - RSA 4096
bits
If committers have a DSA or RSA key of less than 2048 bits then a new
one should be generated for signing releases, again using RSA 4096 bit.
For committers who already have an RSA key of 2048 bits or more some
configuration of their client to avoid weaknesses are required.
Instructions on how to do this can be found here.
Kris