You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wookie.apache.org by Kris Popat <kj...@gmail.com> on 2010/10/06 11:57:54 UTC
Wookie Release Process
Hi All,
I've spent some time going through the apache release process and
going through wookie itself. I think I've got the process straight
but mentors please keep me right on this. Some or many of these
processes may already have been done or started. Here is an outline
list of what I've extracted from the documentation that Ross pointed
me towards (thank you Ross) and other docs on the apache site.
Analyze Open Issues - as a community we need to decide which issues
and bugs can/must be resolved for this release and which we may
postpone for future releases.
Signing the release - not fully sure of the process of this part, but
I create a key well in advance of the release to be uploaded with the
release when or if we get to that point. Have looked at http://www.apache.org/dev/release-signing.html
to understand this.
Make sure we're all happy with release name apache-wookie-incubating
License Audit/Legal Audit
Check files headers
Recheck dependencies
Create LICENCE and NOTICE files - including licenses etc from all
dependencies
Documentation
Finalize all current documentation
Check all current documentation
Discuss if other documentation is required
Status Document?
Create Release Notes including standard incubator disclaimer
Create a release branch on SVN - this to become a snapshot of of the
complete release package
Make sure permissions are set correctly
When the release branch is complete this becomes the release candidate
which is then compressed and posted - probably in my apache home
directory
Test the package
Hold a vote for the release
If the vote is successful request approval from the Incubator PCM
If he request is approved the release is uploaded to the incubator
distribution directory
Mirroring (do we need to do anything for this??)
Archiving - I assume that as this is the first release this is not
applicable
Check permissions
Update wookie website
There is quite a lot more detail to the process that I have not put in
this email, but I'm hoping I have the main points here. Please let me
know what I have missed or misunderstood.
Kris
Re: Wookie Release Process
Posted by Ross Gardler <rg...@apache.org>.
On 07/10/2010 16:52, Kris Popat wrote:
> It might be an idea at this point to put a time line on the release
> process so those who might produce a patch know when as well as what
> (this may apply to other issues). If we are aiming for ApacheCon NA then
> we have about 3 weeks for the whole process - giving some time for
> propagation through the mirrors. I'll create a timeline based upon a
> modified release schedule (thanks Ross for the comments) and see how it
> looks.
Agreed. You might find the timeline we use on Simal useful as a guide
See the "keeping the community informed" section of
http://code.google.com/p/simal/wiki/ReleaseManagement.
Ross
Re: Wookie Release Process
Posted by Ross Gardler <rg...@apache.org>.
On 07/10/2010 20:04, Scott Wilson wrote:
...
>>>>> (NB I've assumed the release we're doing now is 0.8.1 and therefore a
>>>>> future release would be 0.8.2.)
>>>>
>>>> I wonder if we ought to make it a 0.9. There have been some significant improvements since 0.8 (no MySQL, standalone mode, built in demos). The issues above would therefore all be 0.9.1 issues.
>>>>
>>>
>>> I'm happy with that so
>>> +1
>> + 1
>
> +1 from me too. I presume there is some magic in Jira that will "make it so".
Yes. I've made the changes. For bulk changes do a filter for the issues
you want to change, there is a bulk change in the upper right of the
results. Although for this particular activity there is a merge feature
Changes I made:
- create 0.9.0 and merged 0.8.1 into it
- create 0.9.1 and merged 0.8.2 into it
- create 0.9.2 and merged 0.8.3 into it
Ross
Re: Wookie Release Process
Posted by Scott Wilson <sc...@gmail.com>.
On 7 Oct 2010, at 18:26, Paul Sharples wrote:
WOOKIE-67 Implement localization of widgets on per-instance basis ->
>>>> WOOKIE-93 Implementing charset selection for start files This is the
>>>> last remaining peace of the localisation issue - dynamic charset
>>>> overrides by widget start files. However its not a blocker for a
>>>> release as we try to serve everything as UTF-8 by default, so I
>>>> suggest moving it to 0.8.2.
>>> +1
>> +1
> + 1
DONE
>>> WOOKIE-19 Write server admin guide We have a doc review as part of
>>>> the release process, so I suggest we close this once we're past that
>>>> step.
>>> +1
>> +1
> + 1
OK
>>>> WOOKIE-44 Default widget returns js "error" when loaded into a
>>>> browser This directly affects users on IE8/9, so we should fix this
>>>> now. Paul had already started the investigation on this, so may be
>>>> able to provide a fix?
>>>
>>> Lets not delay the release for this, but instead make sure it is clearly documented (ideally the widget will do a browser detection and report the problem linking to the issue - maybe we'll get a patch).
>>>
>>
>> If the fix for this is quick then it would be good to get it done. However, if it may take a little longer I'm in agreement with Ross
>>
> One way could be to add the browser detection for IE8 to the wookie-wrapper.js and report the problem from there, that way all widgets will handle the issue in the same way. I'll look into it.
> BTW: I've been hacking around with IE9 beta and initially at least, it looks as though this problem has been resolved (although i need to test it more thoroughly). Pity its still a beta - most users won't yet have it.
OK, over to you on this one!
>>>> WOOKIE-119 Author info does not support bidirectional text There is
>>>> basic support at the parser level; in practice you can use UTF-8
>>>> control characters now anyway - this adds more control in markup
>>>> (e.g. for combinations of LTR and RTL text). I don't however see this
>>>> as a release blocker, and we can fix this in 0.8.2.
>>> +1
>> +1
> + 1
DONE
>>>
>>>> WOOKIE-111 Enable support for virtual hosts This is something we
>>>> should look at, but it potentially touches a lot of areas of the
>>>> server and configuration and needs a lot of testing. I'd opt to
>>>> postpone this one to 0.8.2. (It's also entirely possible there are
>>>> workarounds and we just need to document them)
>>>
>>> Another good one for us to document clearly in the readme. It sounds like the kind of thing someone might just know how to do, lets ask for a documentation patch.
>> +1
> + 1
I've added a placeholder in the wiki and pointer to it from the README, and moved the issue to 0.8.2
>>>> WOOKIE-90 JQuery document ready function not working This affects
>>>> widget developers now, so if possible we should try to fix this.
>>>
>>> There is a workaround for this. Lets document it in the readme and get the release out. If someone gets a patch in before the code freeze then all the good, but this is the kind of thing that could indefinitely hold up a release.
>>>
>>
>> +1
> + 1
OK, added an FAQ entry for this and moved to 0.8.2.
>>
>> It might be an idea at this point to put a time line on the release process so those who might produce a patch know when as well as what (this may apply to other issues). If we are aiming for ApacheCon NA then we have about 3 weeks for the whole process - giving some time for propagation through the mirrors. I'll create a timeline based upon a modified release schedule (thanks Ross for the comments) and see how it looks.
>>
>>>> WOOKIE-81 Ensure all code has license headers This is part of our
>>>> release process anyway, so we should close this once we've done our
>>>> due diligence on licenses.
>>> +1
>> +1
> +1
OK
>>>> (NB I've assumed the release we're doing now is 0.8.1 and therefore a
>>>> future release would be 0.8.2.)
>>>
>>> I wonder if we ought to make it a 0.9. There have been some significant improvements since 0.8 (no MySQL, standalone mode, built in demos). The issues above would therefore all be 0.9.1 issues.
>>>
>>
>> I'm happy with that so
>> +1
> + 1
+1 from me too. I presume there is some magic in Jira that will "make it so".
Re: Wookie Release Process
Posted by Paul Sharples <p....@bolton.ac.uk>.
On 07/10/2010 16:52, Kris Popat wrote:
>
> On 7 Oct 2010, at 16:31, Ross Gardler wrote:
>
>> On 07/10/2010 14:36, Scott Wilson wrote:
>>>
>>> On 7 Oct 2010, at 13:35, Ross Gardler wrote:
>>>
>>>> On 07/10/2010 13:10, Scott Wilson wrote:
>>>>> On 6 Oct 2010, at 11:45, Ross Gardler wrote:
>>>>>
>>>>>> On 06/10/2010 10:57, Kris Popat wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I've spent some time going through the apache release process
>>>>>>> and going through wookie itself. I think I've got the process
>>>>>>> straight but mentors please keep me right on this. Some or
>>>>>>> many of these processes may already have been done or
>>>>>>> started. Here is an outline list of what I've extracted from
>>>>>>> the documentation that Ross pointed me towards (thank you
>>>>>>> Ross) and other docs on the apache site.
>>>>>>>
>>>>>>>
>>>>>>> Analyze Open Issues - as a community we need to decide which
>>>>>>> issues and bugs can/must be resolved for this release and
>>>>>>> which we may postpone for future releases.
>>>>>>
>>>>>> We can all help here.
>>>>>
>>>>> We also need to Resolve the Closed issues against 0.8.1 - as I
>>>>> closed quite a few of them I shouldn't verify them myself.
>>>>
>>>> I suggest we do that as part of the test cycle. It will ensure that
>>>> at least one person has conducted fairly rigourous tests.
>>>
>>> Yes - and to Verify an issue we should document how it was tested
>>> (and preferably, add JUnit tests to do it automatically in future.)
>>
>> +1
>>
>
> +1
+ 1
>
>> In future we probably want to make this part of our development
>> process not part of the release process. However, I don't think we
>> want to delay a release for the test harnesses at this point.
>>
>
> Agreed
>
>>>>> Once we've done that there will be only 8 issues left to decide
>>>>> on.
>>>>
>>>> Cool. I wonder if you could post their subjects here and your
>>>> proposal. In most cases I suspect we'll just +1 what you propose
>>>> ;-)
>>>
>>> WOOKIE-67 Implement localization of widgets on per-instance basis ->
>>> WOOKIE-93 Implementing charset selection for start files This is the
>>> last remaining peace of the localisation issue - dynamic charset
>>> overrides by widget start files. However its not a blocker for a
>>> release as we try to serve everything as UTF-8 by default, so I
>>> suggest moving it to 0.8.2.
>>
>> +1
>
> +1
+ 1
>
>>
>>> WOOKIE-19 Write server admin guide We have a doc review as part of
>>> the release process, so I suggest we close this once we're past that
>>> step.
>>
>> +1
>>
>
> +1
+ 1
>
>>> WOOKIE-44 Default widget returns js "error" when loaded into a
>>> browser This directly affects users on IE8/9, so we should fix this
>>> now. Paul had already started the investigation on this, so may be
>>> able to provide a fix?
>>
>> Lets not delay the release for this, but instead make sure it is
>> clearly documented (ideally the widget will do a browser detection
>> and report the problem linking to the issue - maybe we'll get a patch).
>>
>
> If the fix for this is quick then it would be good to get it done.
> However, if it may take a little longer I'm in agreement with Ross
>
One way could be to add the browser detection for IE8 to the
wookie-wrapper.js and report the problem from there, that way all
widgets will handle the issue in the same way. I'll look into it.
BTW: I've been hacking around with IE9 beta and initially at least, it
looks as though this problem has been resolved (although i need to test
it more thoroughly). Pity its still a beta - most users won't yet have it.
>>> WOOKIE-119 Author info does not support bidirectional text There is
>>> basic support at the parser level; in practice you can use UTF-8
>>> control characters now anyway - this adds more control in markup
>>> (e.g. for combinations of LTR and RTL text). I don't however see this
>>> as a release blocker, and we can fix this in 0.8.2.
>>
>> +1
>
> +1
>
+ 1
>>
>>> WOOKIE-111 Enable support for virtual hosts This is something we
>>> should look at, but it potentially touches a lot of areas of the
>>> server and configuration and needs a lot of testing. I'd opt to
>>> postpone this one to 0.8.2. (It's also entirely possible there are
>>> workarounds and we just need to document them)
>>
>> Another good one for us to document clearly in the readme. It sounds
>> like the kind of thing someone might just know how to do, lets ask
>> for a documentation patch.
>>
>
> +1
>
+ 1
>>> WOOKIE-90 JQuery document ready function not working This affects
>>> widget developers now, so if possible we should try to fix this.
>>
>> There is a workaround for this. Lets document it in the readme and
>> get the release out. If someone gets a patch in before the code
>> freeze then all the good, but this is the kind of thing that could
>> indefinitely hold up a release.
>>
>
> +1
+ 1
>
> It might be an idea at this point to put a time line on the release
> process so those who might produce a patch know when as well as what
> (this may apply to other issues). If we are aiming for ApacheCon NA
> then we have about 3 weeks for the whole process - giving some time
> for propagation through the mirrors. I'll create a timeline based
> upon a modified release schedule (thanks Ross for the comments) and
> see how it looks.
>
>>> WOOKIE-81 Ensure all code has license headers This is part of our
>>> release process anyway, so we should close this once we've done our
>>> due diligence on licenses.
>>
>> +1
>
> +1
+1
>
>>
>>> (NB I've assumed the release we're doing now is 0.8.1 and therefore a
>>> future release would be 0.8.2.)
>>
>> I wonder if we ought to make it a 0.9. There have been some
>> significant improvements since 0.8 (no MySQL, standalone mode, built
>> in demos). The issues above would therefore all be 0.9.1 issues.
>>
>
> I'm happy with that so
> +1
+ 1
>
> Kris
>
Re: Wookie Release Process
Posted by Kris Popat <kj...@gmail.com>.
On 7 Oct 2010, at 16:31, Ross Gardler wrote:
> On 07/10/2010 14:36, Scott Wilson wrote:
>>
>> On 7 Oct 2010, at 13:35, Ross Gardler wrote:
>>
>>> On 07/10/2010 13:10, Scott Wilson wrote:
>>>> On 6 Oct 2010, at 11:45, Ross Gardler wrote:
>>>>
>>>>> On 06/10/2010 10:57, Kris Popat wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> I've spent some time going through the apache release process
>>>>>> and going through wookie itself. I think I've got the process
>>>>>> straight but mentors please keep me right on this. Some or
>>>>>> many of these processes may already have been done or
>>>>>> started. Here is an outline list of what I've extracted from
>>>>>> the documentation that Ross pointed me towards (thank you
>>>>>> Ross) and other docs on the apache site.
>>>>>>
>>>>>>
>>>>>> Analyze Open Issues - as a community we need to decide which
>>>>>> issues and bugs can/must be resolved for this release and
>>>>>> which we may postpone for future releases.
>>>>>
>>>>> We can all help here.
>>>>
>>>> We also need to Resolve the Closed issues against 0.8.1 - as I
>>>> closed quite a few of them I shouldn't verify them myself.
>>>
>>> I suggest we do that as part of the test cycle. It will ensure that
>>> at least one person has conducted fairly rigourous tests.
>>
>> Yes - and to Verify an issue we should document how it was tested
>> (and preferably, add JUnit tests to do it automatically in future.)
>
> +1
>
+1
> In future we probably want to make this part of our development
> process not part of the release process. However, I don't think we
> want to delay a release for the test harnesses at this point.
>
Agreed
>>>> Once we've done that there will be only 8 issues left to decide
>>>> on.
>>>
>>> Cool. I wonder if you could post their subjects here and your
>>> proposal. In most cases I suspect we'll just +1 what you propose
>>> ;-)
>>
>> WOOKIE-67 Implement localization of widgets on per-instance basis ->
>> WOOKIE-93 Implementing charset selection for start files This is the
>> last remaining peace of the localisation issue - dynamic charset
>> overrides by widget start files. However its not a blocker for a
>> release as we try to serve everything as UTF-8 by default, so I
>> suggest moving it to 0.8.2.
>
> +1
+1
>
>> WOOKIE-19 Write server admin guide We have a doc review as part of
>> the release process, so I suggest we close this once we're past that
>> step.
>
> +1
>
+1
>> WOOKIE-44 Default widget returns js "error" when loaded into a
>> browser This directly affects users on IE8/9, so we should fix this
>> now. Paul had already started the investigation on this, so may be
>> able to provide a fix?
>
> Lets not delay the release for this, but instead make sure it is
> clearly documented (ideally the widget will do a browser detection
> and report the problem linking to the issue - maybe we'll get a
> patch).
>
If the fix for this is quick then it would be good to get it done.
However, if it may take a little longer I'm in agreement with Ross
>> WOOKIE-119 Author info does not support bidirectional text There is
>> basic support at the parser level; in practice you can use UTF-8
>> control characters now anyway - this adds more control in markup
>> (e.g. for combinations of LTR and RTL text). I don't however see this
>> as a release blocker, and we can fix this in 0.8.2.
>
> +1
+1
>
>> WOOKIE-111 Enable support for virtual hosts This is something we
>> should look at, but it potentially touches a lot of areas of the
>> server and configuration and needs a lot of testing. I'd opt to
>> postpone this one to 0.8.2. (It's also entirely possible there are
>> workarounds and we just need to document them)
>
> Another good one for us to document clearly in the readme. It sounds
> like the kind of thing someone might just know how to do, lets ask
> for a documentation patch.
>
+1
>> WOOKIE-90 JQuery document ready function not working This affects
>> widget developers now, so if possible we should try to fix this.
>
> There is a workaround for this. Lets document it in the readme and
> get the release out. If someone gets a patch in before the code
> freeze then all the good, but this is the kind of thing that could
> indefinitely hold up a release.
>
+1
It might be an idea at this point to put a time line on the release
process so those who might produce a patch know when as well as what
(this may apply to other issues). If we are aiming for ApacheCon NA
then we have about 3 weeks for the whole process - giving some time
for propagation through the mirrors. I'll create a timeline based
upon a modified release schedule (thanks Ross for the comments) and
see how it looks.
>> WOOKIE-81 Ensure all code has license headers This is part of our
>> release process anyway, so we should close this once we've done our
>> due diligence on licenses.
>
> +1
+1
>
>> (NB I've assumed the release we're doing now is 0.8.1 and therefore a
>> future release would be 0.8.2.)
>
> I wonder if we ought to make it a 0.9. There have been some
> significant improvements since 0.8 (no MySQL, standalone mode, built
> in demos). The issues above would therefore all be 0.9.1 issues.
>
I'm happy with that so
+1
Kris
Re: Wookie Release Process
Posted by Ross Gardler <rg...@apache.org>.
On 07/10/2010 14:36, Scott Wilson wrote:
>
> On 7 Oct 2010, at 13:35, Ross Gardler wrote:
>
>> On 07/10/2010 13:10, Scott Wilson wrote:
>>> On 6 Oct 2010, at 11:45, Ross Gardler wrote:
>>>
>>>> On 06/10/2010 10:57, Kris Popat wrote:
>>>>> Hi All,
>>>>>
>>>>> I've spent some time going through the apache release process
>>>>> and going through wookie itself. I think I've got the process
>>>>> straight but mentors please keep me right on this. Some or
>>>>> many of these processes may already have been done or
>>>>> started. Here is an outline list of what I've extracted from
>>>>> the documentation that Ross pointed me towards (thank you
>>>>> Ross) and other docs on the apache site.
>>>>>
>>>>>
>>>>> Analyze Open Issues - as a community we need to decide which
>>>>> issues and bugs can/must be resolved for this release and
>>>>> which we may postpone for future releases.
>>>>
>>>> We can all help here.
>>>
>>> We also need to Resolve the Closed issues against 0.8.1 - as I
>>> closed quite a few of them I shouldn't verify them myself.
>>
>> I suggest we do that as part of the test cycle. It will ensure that
>> at least one person has conducted fairly rigourous tests.
>
> Yes - and to Verify an issue we should document how it was tested
> (and preferably, add JUnit tests to do it automatically in future.)
+1
In future we probably want to make this part of our development process
not part of the release process. However, I don't think we want to delay
a release for the test harnesses at this point.
>>> Once we've done that there will be only 8 issues left to decide
>>> on.
>>
>> Cool. I wonder if you could post their subjects here and your
>> proposal. In most cases I suspect we'll just +1 what you propose
>> ;-)
>
> WOOKIE-67 Implement localization of widgets on per-instance basis ->
> WOOKIE-93 Implementing charset selection for start files This is the
> last remaining peace of the localisation issue - dynamic charset
> overrides by widget start files. However its not a blocker for a
> release as we try to serve everything as UTF-8 by default, so I
> suggest moving it to 0.8.2.
+1
> WOOKIE-19 Write server admin guide We have a doc review as part of
> the release process, so I suggest we close this once we're past that
> step.
+1
> WOOKIE-44 Default widget returns js "error" when loaded into a
> browser This directly affects users on IE8/9, so we should fix this
> now. Paul had already started the investigation on this, so may be
> able to provide a fix?
Lets not delay the release for this, but instead make sure it is clearly
documented (ideally the widget will do a browser detection and report
the problem linking to the issue - maybe we'll get a patch).
> WOOKIE-119 Author info does not support bidirectional text There is
> basic support at the parser level; in practice you can use UTF-8
> control characters now anyway - this adds more control in markup
> (e.g. for combinations of LTR and RTL text). I don't however see this
> as a release blocker, and we can fix this in 0.8.2.
+1
> WOOKIE-111 Enable support for virtual hosts This is something we
> should look at, but it potentially touches a lot of areas of the
> server and configuration and needs a lot of testing. I'd opt to
> postpone this one to 0.8.2. (It's also entirely possible there are
> workarounds and we just need to document them)
Another good one for us to document clearly in the readme. It sounds
like the kind of thing someone might just know how to do, lets ask for a
documentation patch.
> WOOKIE-90 JQuery document ready function not working This affects
> widget developers now, so if possible we should try to fix this.
There is a workaround for this. Lets document it in the readme and get
the release out. If someone gets a patch in before the code freeze then
all the good, but this is the kind of thing that could indefinitely hold
up a release.
> WOOKIE-81 Ensure all code has license headers This is part of our
> release process anyway, so we should close this once we've done our
> due diligence on licenses.
+1
> (NB I've assumed the release we're doing now is 0.8.1 and therefore a
> future release would be 0.8.2.)
I wonder if we ought to make it a 0.9. There have been some significant
improvements since 0.8 (no MySQL, standalone mode, built in demos). The
issues above would therefore all be 0.9.1 issues.
Ross
Re: Wookie Release Process
Posted by Scott Wilson <sc...@gmail.com>.
On 7 Oct 2010, at 13:35, Ross Gardler wrote:
> On 07/10/2010 13:10, Scott Wilson wrote:
>> On 6 Oct 2010, at 11:45, Ross Gardler wrote:
>>
>>> On 06/10/2010 10:57, Kris Popat wrote:
>>>> Hi All,
>>>>
>>>> I've spent some time going through the apache release process and going
>>>> through wookie itself. I think I've got the process straight but mentors
>>>> please keep me right on this. Some or many of these processes may
>>>> already have been done or started. Here is an outline list of what I've
>>>> extracted from the documentation that Ross pointed me towards (thank you
>>>> Ross) and other docs on the apache site.
>>>>
>>>>
>>>> Analyze Open Issues - as a community we need to decide which issues and
>>>> bugs can/must be resolved for this release and which we may postpone for
>>>> future releases.
>>>
>>> We can all help here.
>>
>> We also need to Resolve the Closed issues against 0.8.1 - as I closed quite a few of them I shouldn't verify them myself.
>
> I suggest we do that as part of the test cycle. It will ensure that at least one person has conducted fairly rigourous tests.
Yes - and to Verify an issue we should document how it was tested (and preferably, add JUnit tests to do it automatically in future.)
>> Once we've done that there will be only 8 issues left to decide on.
>
> Cool. I wonder if you could post their subjects here and your proposal. In most cases I suspect we'll just +1 what you propose ;-)
WOOKIE-67 Implement localization of widgets on per-instance basis
-> WOOKIE-93 Implementing charset selection for start files
This is the last remaining peace of the localisation issue - dynamic charset overrides by widget start files. However its not a blocker for a release as we try to serve everything as UTF-8 by default, so I suggest moving it to 0.8.2.
WOOKIE-19 Write server admin guide
We have a doc review as part of the release process, so I suggest we close this once we're past that step.
WOOKIE-44 Default widget returns js "error" when loaded into a browser
This directly affects users on IE8/9, so we should fix this now. Paul had already started the investigation on this, so may be able to provide a fix?
WOOKIE-119 Author info does not support bidirectional text
There is basic support at the parser level; in practice you can use UTF-8 control characters now anyway - this adds more control in markup (e.g. for combinations of LTR and RTL text). I don't however see this as a release blocker, and we can fix this in 0.8.2.
WOOKIE-111 Enable support for virtual hosts
This is something we should look at, but it potentially touches a lot of areas of the server and configuration and needs a lot of testing. I'd opt to postpone this one to 0.8.2. (It's also entirely possible there are workarounds and we just need to document them)
WOOKIE-90 JQuery document ready function not working
This affects widget developers now, so if possible we should try to fix this.
WOOKIE-81 Ensure all code has license headers
This is part of our release process anyway, so we should close this once we've done our due diligence on licenses.
(NB I've assumed the release we're doing now is 0.8.1 and therefore a future release would be 0.8.2.)
>
> Ross
Re: Wookie Release Process
Posted by Ross Gardler <rg...@apache.org>.
On 07/10/2010 13:10, Scott Wilson wrote:
> On 6 Oct 2010, at 11:45, Ross Gardler wrote:
>
>> On 06/10/2010 10:57, Kris Popat wrote:
>>> Hi All,
>>>
>>> I've spent some time going through the apache release process and going
>>> through wookie itself. I think I've got the process straight but mentors
>>> please keep me right on this. Some or many of these processes may
>>> already have been done or started. Here is an outline list of what I've
>>> extracted from the documentation that Ross pointed me towards (thank you
>>> Ross) and other docs on the apache site.
>>>
>>>
>>> Analyze Open Issues - as a community we need to decide which issues and
>>> bugs can/must be resolved for this release and which we may postpone for
>>> future releases.
>>
>> We can all help here.
>
> We also need to Resolve the Closed issues against 0.8.1 - as I closed quite a few of them I shouldn't verify them myself.
I suggest we do that as part of the test cycle. It will ensure that at
least one person has conducted fairly rigourous tests.
> Once we've done that there will be only 8 issues left to decide on.
Cool. I wonder if you could post their subjects here and your proposal.
In most cases I suspect we'll just +1 what you propose ;-)
Ross
Re: Wookie Release Process
Posted by Scott Wilson <sc...@gmail.com>.
On 6 Oct 2010, at 11:45, Ross Gardler wrote:
> On 06/10/2010 10:57, Kris Popat wrote:
>> Hi All,
>>
>> I've spent some time going through the apache release process and going
>> through wookie itself. I think I've got the process straight but mentors
>> please keep me right on this. Some or many of these processes may
>> already have been done or started. Here is an outline list of what I've
>> extracted from the documentation that Ross pointed me towards (thank you
>> Ross) and other docs on the apache site.
>>
>>
>> Analyze Open Issues - as a community we need to decide which issues and
>> bugs can/must be resolved for this release and which we may postpone for
>> future releases.
>
> We can all help here.
We also need to Resolve the Closed issues against 0.8.1 - as I closed quite a few of them I shouldn't verify them myself.
Once we've done that there will be only 8 issues left to decide on.
Re: Wookie Release Process
Posted by Ross Gardler <rg...@apache.org>.
On 06/10/2010 10:57, Kris Popat wrote:
> Hi All,
>
> I've spent some time going through the apache release process and going
> through wookie itself. I think I've got the process straight but mentors
> please keep me right on this. Some or many of these processes may
> already have been done or started. Here is an outline list of what I've
> extracted from the documentation that Ross pointed me towards (thank you
> Ross) and other docs on the apache site.
>
>
> Analyze Open Issues - as a community we need to decide which issues and
> bugs can/must be resolved for this release and which we may postpone for
> future releases.
We can all help here.
> Signing the release - not fully sure of the process of this part, but I
> create a key well in advance of the release to be uploaded with the
> release when or if we get to that point. Have looked at
> http://www.apache.org/dev/release-signing.html to understand this.
Not just you, everyone. We should all sign the release to maximise the
chances of there web of trust working for people
> Make sure we're all happy with release name apache-wookie-incubating
No choice about that at this point, but what will the version number be?
> License Audit/Legal Audit
We should not rely on the tools for this. There does need to be a manual
check of things like notice files.
> Check files headers
In general the tools are fine for this (along with reviews on commit).
However, manual checks should be done (someone in the incubator PMC will
do this check very thoroughly so lets try not to waste anyones time).
> Recheck dependencies
What are we checking here? I'd suggest:
- all dependencies are actually required
- all dependencies are the latest release (and tested)
- all dependencies are retrievable by IVY on a clean machine (or
documented accordingly)
> Create LICENCE and NOTICE files - including licenses etc from all
> dependencies
Yes, I rolled this into legal audit above.
> Documentation
> Finalize all current documentation
> Check all current documentation
> Discuss if other documentation is required
In general I would say that documentation should be checked for
installation and build accuracy but that other aspects should not hold
up the release. We don't bundle the documentation with the release and
thus we can modify it as and when things are required by our user
community. That being said, we need to actively encourage users to help
with documentation issues.
> Status Document?
This can largely be generated from the issues tracker, but we will need
a para or two intro.
> Create Release Notes including standard incubator disclaimer
> Create a release branch on SVN - this to become a snapshot of of the
> complete release package
> Make sure permissions are set correctly
> When the release branch is complete this becomes the release candidate
> which is then compressed and posted - probably in my apache home directory
> Test the package
Testing is very, very important. We need everyone on the dev list to
test the release candidate in their environment.
> Hold a vote for the release
> If the vote is successful request approval from the Incubator PCM
> If he request is approved the release is uploaded to the incubator
> distribution directory
> Mirroring (do we need to do anything for this??)
I don't think it is necessary to do anything special as long as the
upload instructions are followed. However, we should check the details
when we get to this stage.
Remember we need to wait a while so mirrors catch up before announcing
the release.
> Archiving - I assume that as this is the first release this is not
> applicable
agreed.
> Check permissions
> Update wookie website
>
> There is quite a lot more detail to the process that I have not put in
> this email, but I'm hoping I have the main points here. Please let me
> know what I have missed or misunderstood.
You missed out the signing process (mentioned preparing by generating
keys but not the signing of the binaries), this needs to be tested too.
Thanks for getting this started. I'd like to remind you to ensure this
kind of documentation is kept in our wiki so that the next release
manager need not duplicate your efforts here.
I'd be really happy if we can manage to get a release our before
ApacheCon NA as I am doing a presentation on Wookie there. If not the
final official release a package for me to ask people to test would be
great.
Thanks,
Ross