You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by Gabriela Gibson <ga...@gmail.com> on 2015/08/23 21:37:20 UTC

Do we have/want a check list for releases?

On Sun, Aug 23, 2015 at 8:18 PM, Andrea Pescetti <pe...@apache.org> wrote:

<snipped some complex procedural discussion>

> It is not mandatory, but very useful (and I would
> make a recommendation out of it) that when voting on a release one doesn't
> simply cast a +1 as such.
>
> I mean, of course a -1 must always be explained, but a +1 should be
> explained too, like this:
> "+1 Built source on Windows, checked README files, checked ALv2 headers"
> "+1 Did only a cursory review but I trust you guys on the code"
> and so on.
>
> Remember, the PPMC is assumed (whether this is written somewhere or not) to
> give a +1 based on (mainly) technical reasons; the IPMC will take this for
> granted and (broadly speaking) mainly look for compliance issues. If from
> the set of PPMC votes the Release Manager can understand, for example, that
> no testing at all was done on Linux, he may decide to extend the VOTE until
> Linux gets proper coverage; if the PPMC members do not supply this
> information, we can't know what was tested and what not.
>
> So, Jan's question was not for me, but in terms of the "proper technical
> review" it would help to see VOTE e-mails more informative than a simple +1,
> so that one can be sure that all areas are covered.
>
> [Feel free to quote/forward this message in public]
>
> Regards,
>   Andrea.

This makes me think that perhaps having an official check list to
ensure that nothing gets forgotten and to make the splitting of the
large task that a release is easy and focus resources more efficiently
may be a very useful tool to have.

What do other projects do in this regard?

G
-- 
Visit my Coding Diary: http://gabriela-gibson.blogspot.com/

Re: Do we have/want a check list for releases?

Posted by Gabriela Gibson <ga...@gmail.com>.
Hi,

Brane got back to me, and alas, Voter is defunct and he is removing
the link from the page.

G

On Mon, Aug 24, 2015 at 4:08 AM, Gabriela Gibson
<ga...@gmail.com> wrote:
> On Mon, Aug 24, 2015 at 2:52 AM, Dave Fisher <da...@comcast.net> wrote:
>
>> (3) Voter - how to check IP from both the ASF requirements and also the project's. We can choose our own standards for quality. The ASF is not concerned if the code works, but the project community does care.
>
> I located it, but it does not appear to be functional.  I emailed
> Brane (since the broken page points to his home directory (I think))
> and asked.  It probably was moved and the link on
>
> http://incubator.apache.org/facilities.html
>
> is just stale.
>
> Will report back on status once he gets back to me.
>
> G
> --
> Visit my Coding Diary: http://gabriela-gibson.blogspot.com/



-- 
Visit my Coding Diary: http://gabriela-gibson.blogspot.com/

Re: Do we have/want a check list for releases?

Posted by Gabriela Gibson <ga...@gmail.com>.
Whilst I am on a roll, I also made a Wiki-how to page.

https://cwiki.apache.org/confluence/display/Corinthia/Release+Checklist

This is currently a stub, let's go fill it.

Please keep entries short, I would suggest that long instructions
should go onto a sub page that is linked from the how-to page and that
the main page is kept as a directory that lists those.

It also looks like the wiki software has been updated and lots of new
stuff has been added.  Snazzy!  Go check it out.

G

On Mon, Aug 24, 2015 at 4:08 AM, Gabriela Gibson
<ga...@gmail.com> wrote:
> On Mon, Aug 24, 2015 at 2:52 AM, Dave Fisher <da...@comcast.net> wrote:
>
>> (3) Voter - how to check IP from both the ASF requirements and also the project's. We can choose our own standards for quality. The ASF is not concerned if the code works, but the project community does care.
>
> I located it, but it does not appear to be functional.  I emailed
> Brane (since the broken page points to his home directory (I think))
> and asked.  It probably was moved and the link on
>
> http://incubator.apache.org/facilities.html
>
> is just stale.
>
> Will report back on status once he gets back to me.
>
> G
> --
> Visit my Coding Diary: http://gabriela-gibson.blogspot.com/



-- 
Visit my Coding Diary: http://gabriela-gibson.blogspot.com/

Re: Do we have/want a check list for releases?

Posted by Gabriela Gibson <ga...@gmail.com>.
On Mon, Aug 24, 2015 at 2:52 AM, Dave Fisher <da...@comcast.net> wrote:

> (3) Voter - how to check IP from both the ASF requirements and also the project's. We can choose our own standards for quality. The ASF is not concerned if the code works, but the project community does care.

I located it, but it does not appear to be functional.  I emailed
Brane (since the broken page points to his home directory (I think))
and asked.  It probably was moved and the link on

http://incubator.apache.org/facilities.html

is just stale.

Will report back on status once he gets back to me.

G
-- 
Visit my Coding Diary: http://gabriela-gibson.blogspot.com/

Re: Do we have/want a check list for releases?

Posted by Dave Fisher <da...@comcast.net>.
+1000

Sent from my iPhone

> On Aug 24, 2015, at 3:31 AM, jan i <ja...@apache.org> wrote:
> 
> Hi
> 
> I have added text to the wiki page, while I still have it fresh in mind. A
> couple of comments (before somebody start
> tossing procedures):
> - I added a link to the official release guide (thanks to Andrea)
> - The 18 steps reflect what I just did + the changes suggested by IPMC
> 
> Disclaimer, this is our version of release management, it follows the
> rules, but e.g. the PRE-VOTE is a extra
> step, which Peter suggested and that turned out to be very useful.
> 
> Feel free to correct the text, but please do not reduce it to "what the
> rulebook says", that will not help us.
> 
> rgds
> jan i.
> 
> 
> On 24 August 2015 at 06:40, Dennis E. Hamilton <de...@acm.org>
> wrote:
> 
>> A nice collection.  I don't know of anything better.
>> 
>> If you want to see how it goes for other projects, especially podlings,
>> subscribe to general@incubator.apache.org and there will be plenty of
>> discussion.
>> 
>> - Dennis
>> 
>> -----Original Message-----
>> From: Gabriela Gibson [mailto:gabriela.gibson@gmail.com]
>> Sent: Sunday, August 23, 2015 19:57
>> To: dev@corinthia.incubator.apache.org
>> Subject: Re: Do we have/want a check list for releases?
>> 
>> Thanks for the hint Dave, here are the links:
>> 
>> http://incubator.apache.org/guides/releasemanagement.html
>> 
>> http://wiki.apache.org/incubator/ReleaseChecklist
>> 
>> http://incubator.apache.org/guides/release.html
>> 
>> http://wiki.apache.org/incubator/SigningReleases
>> 
>> there are probably more, but I think this is a good start.
>> 
>> I would suggest that everyone has a little bit of a read over the next
>> two weeks and that we then combine ideas into a 'how to' for the next
>> release and refine that as we gain more experience.
>> 
>> G
>> 
>> On Mon, Aug 24, 2015 at 2:52 AM, Dave Fisher <da...@comcast.net>
>> wrote:
>>> Here are two ideas that other projects do.
>>> 
>>> (1) Have a target in the build or a script that creates all the release
>> artifacts.
>>> 
>>> (2) include Apache RAT to run license checks  as part of the build.
>>> 
>>> Look at the emails at the emails from IPMC members on what was done as
>> part of the vote.
>>> 
>>> Corinthia will certainly have our own unique differences based what
>> artifacts we decide to create.
>>> 
>>> I think there are probably three check lists.
>>> 
>>> (1) Release Packaging - what is being released.
>>> 
>>> (2) Release Manager - how to build, vote and distribute. POI has almost
>> all of this as Ant targets. This can make it easy to for anyone to be RM
>>> 
>>> (3) Voter - how to check IP from both the ASF requirements and also the
>> project's. We can choose our own standards for quality. The ASF is not
>> concerned if the code works, but the project community does care.
>>> 
>>> The incubator has wikis with policies and draft policies I would provide
>> the links but I am away from my computer. Perhaps Dennis can provide the
>> links.
>>> 
>>> Regards,
>>> Dave
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Aug 23, 2015, at 12:37 PM, Gabriela Gibson <
>> gabriela.gibson@gmail.com> wrote:
>>>> 
>>>> On Sun, Aug 23, 2015 at 8:18 PM, Andrea Pescetti <pe...@apache.org>
>> wrote:
>>>> 
>>>> <snipped some complex procedural discussion>
>>>> 
>>>>> It is not mandatory, but very useful (and I would
>>>>> make a recommendation out of it) that when voting on a release one
>> doesn't
>>>>> simply cast a +1 as such.
>>>>> 
>>>>> I mean, of course a -1 must always be explained, but a +1 should be
>>>>> explained too, like this:
>>>>> "+1 Built source on Windows, checked README files, checked ALv2
>> headers"
>>>>> "+1 Did only a cursory review but I trust you guys on the code"
>>>>> and so on.
>>>>> 
>>>>> Remember, the PPMC is assumed (whether this is written somewhere or
>> not) to
>>>>> give a +1 based on (mainly) technical reasons; the IPMC will take this
>> for
>>>>> granted and (broadly speaking) mainly look for compliance issues. If
>> from
>>>>> the set of PPMC votes the Release Manager can understand, for example,
>> that
>>>>> no testing at all was done on Linux, he may decide to extend the VOTE
>> until
>>>>> Linux gets proper coverage; if the PPMC members do not supply this
>>>>> information, we can't know what was tested and what not.
>>>>> 
>>>>> So, Jan's question was not for me, but in terms of the "proper
>> technical
>>>>> review" it would help to see VOTE e-mails more informative than a
>> simple +1,
>>>>> so that one can be sure that all areas are covered.
>>>>> 
>>>>> [Feel free to quote/forward this message in public]
>>>>> 
>>>>> Regards,
>>>>> Andrea.
>>>> 
>>>> This makes me think that perhaps having an official check list to
>>>> ensure that nothing gets forgotten and to make the splitting of the
>>>> large task that a release is easy and focus resources more efficiently
>>>> may be a very useful tool to have.
>>>> 
>>>> What do other projects do in this regard?
>>>> 
>>>> G
>>>> --
>>>> Visit my Coding Diary: http://gabriela-gibson.blogspot.com/
>> 
>> 
>> 
>> --
>> Visit my Coding Diary: http://gabriela-gibson.blogspot.com/
>> 
>> 

Re: Do we have/want a check list for releases?

Posted by jan i <ja...@apache.org>.
Hi

I have added text to the wiki page, while I still have it fresh in mind. A
couple of comments (before somebody start
tossing procedures):
- I added a link to the official release guide (thanks to Andrea)
- The 18 steps reflect what I just did + the changes suggested by IPMC

Disclaimer, this is our version of release management, it follows the
rules, but e.g. the PRE-VOTE is a extra
step, which Peter suggested and that turned out to be very useful.

Feel free to correct the text, but please do not reduce it to "what the
rulebook says", that will not help us.

rgds
jan i.


On 24 August 2015 at 06:40, Dennis E. Hamilton <de...@acm.org>
wrote:

> A nice collection.  I don't know of anything better.
>
> If you want to see how it goes for other projects, especially podlings,
> subscribe to general@incubator.apache.org and there will be plenty of
> discussion.
>
>  - Dennis
>
> -----Original Message-----
> From: Gabriela Gibson [mailto:gabriela.gibson@gmail.com]
> Sent: Sunday, August 23, 2015 19:57
> To: dev@corinthia.incubator.apache.org
> Subject: Re: Do we have/want a check list for releases?
>
> Thanks for the hint Dave, here are the links:
>
> http://incubator.apache.org/guides/releasemanagement.html
>
> http://wiki.apache.org/incubator/ReleaseChecklist
>
> http://incubator.apache.org/guides/release.html
>
> http://wiki.apache.org/incubator/SigningReleases
>
> there are probably more, but I think this is a good start.
>
> I would suggest that everyone has a little bit of a read over the next
> two weeks and that we then combine ideas into a 'how to' for the next
> release and refine that as we gain more experience.
>
> G
>
> On Mon, Aug 24, 2015 at 2:52 AM, Dave Fisher <da...@comcast.net>
> wrote:
> > Here are two ideas that other projects do.
> >
> > (1) Have a target in the build or a script that creates all the release
> artifacts.
> >
> > (2) include Apache RAT to run license checks  as part of the build.
> >
> > Look at the emails at the emails from IPMC members on what was done as
> part of the vote.
> >
> > Corinthia will certainly have our own unique differences based what
> artifacts we decide to create.
> >
> > I think there are probably three check lists.
> >
> > (1) Release Packaging - what is being released.
> >
> > (2) Release Manager - how to build, vote and distribute. POI has almost
> all of this as Ant targets. This can make it easy to for anyone to be RM
> >
> > (3) Voter - how to check IP from both the ASF requirements and also the
> project's. We can choose our own standards for quality. The ASF is not
> concerned if the code works, but the project community does care.
> >
> > The incubator has wikis with policies and draft policies I would provide
> the links but I am away from my computer. Perhaps Dennis can provide the
> links.
> >
> > Regards,
> > Dave
> >
> > Sent from my iPhone
> >
> >> On Aug 23, 2015, at 12:37 PM, Gabriela Gibson <
> gabriela.gibson@gmail.com> wrote:
> >>
> >> On Sun, Aug 23, 2015 at 8:18 PM, Andrea Pescetti <pe...@apache.org>
> wrote:
> >>
> >> <snipped some complex procedural discussion>
> >>
> >>> It is not mandatory, but very useful (and I would
> >>> make a recommendation out of it) that when voting on a release one
> doesn't
> >>> simply cast a +1 as such.
> >>>
> >>> I mean, of course a -1 must always be explained, but a +1 should be
> >>> explained too, like this:
> >>> "+1 Built source on Windows, checked README files, checked ALv2
> headers"
> >>> "+1 Did only a cursory review but I trust you guys on the code"
> >>> and so on.
> >>>
> >>> Remember, the PPMC is assumed (whether this is written somewhere or
> not) to
> >>> give a +1 based on (mainly) technical reasons; the IPMC will take this
> for
> >>> granted and (broadly speaking) mainly look for compliance issues. If
> from
> >>> the set of PPMC votes the Release Manager can understand, for example,
> that
> >>> no testing at all was done on Linux, he may decide to extend the VOTE
> until
> >>> Linux gets proper coverage; if the PPMC members do not supply this
> >>> information, we can't know what was tested and what not.
> >>>
> >>> So, Jan's question was not for me, but in terms of the "proper
> technical
> >>> review" it would help to see VOTE e-mails more informative than a
> simple +1,
> >>> so that one can be sure that all areas are covered.
> >>>
> >>> [Feel free to quote/forward this message in public]
> >>>
> >>> Regards,
> >>>  Andrea.
> >>
> >> This makes me think that perhaps having an official check list to
> >> ensure that nothing gets forgotten and to make the splitting of the
> >> large task that a release is easy and focus resources more efficiently
> >> may be a very useful tool to have.
> >>
> >> What do other projects do in this regard?
> >>
> >> G
> >> --
> >> Visit my Coding Diary: http://gabriela-gibson.blogspot.com/
>
>
>
> --
> Visit my Coding Diary: http://gabriela-gibson.blogspot.com/
>
>

RE: Do we have/want a check list for releases?

Posted by "Dennis E. Hamilton" <de...@acm.org>.
A nice collection.  I don't know of anything better.

If you want to see how it goes for other projects, especially podlings, subscribe to general@incubator.apache.org and there will be plenty of discussion.

 - Dennis

-----Original Message-----
From: Gabriela Gibson [mailto:gabriela.gibson@gmail.com] 
Sent: Sunday, August 23, 2015 19:57
To: dev@corinthia.incubator.apache.org
Subject: Re: Do we have/want a check list for releases?

Thanks for the hint Dave, here are the links:

http://incubator.apache.org/guides/releasemanagement.html

http://wiki.apache.org/incubator/ReleaseChecklist

http://incubator.apache.org/guides/release.html

http://wiki.apache.org/incubator/SigningReleases

there are probably more, but I think this is a good start.

I would suggest that everyone has a little bit of a read over the next
two weeks and that we then combine ideas into a 'how to' for the next
release and refine that as we gain more experience.

G

On Mon, Aug 24, 2015 at 2:52 AM, Dave Fisher <da...@comcast.net> wrote:
> Here are two ideas that other projects do.
>
> (1) Have a target in the build or a script that creates all the release artifacts.
>
> (2) include Apache RAT to run license checks  as part of the build.
>
> Look at the emails at the emails from IPMC members on what was done as part of the vote.
>
> Corinthia will certainly have our own unique differences based what artifacts we decide to create.
>
> I think there are probably three check lists.
>
> (1) Release Packaging - what is being released.
>
> (2) Release Manager - how to build, vote and distribute. POI has almost all of this as Ant targets. This can make it easy to for anyone to be RM
>
> (3) Voter - how to check IP from both the ASF requirements and also the project's. We can choose our own standards for quality. The ASF is not concerned if the code works, but the project community does care.
>
> The incubator has wikis with policies and draft policies I would provide the links but I am away from my computer. Perhaps Dennis can provide the links.
>
> Regards,
> Dave
>
> Sent from my iPhone
>
>> On Aug 23, 2015, at 12:37 PM, Gabriela Gibson <ga...@gmail.com> wrote:
>>
>> On Sun, Aug 23, 2015 at 8:18 PM, Andrea Pescetti <pe...@apache.org> wrote:
>>
>> <snipped some complex procedural discussion>
>>
>>> It is not mandatory, but very useful (and I would
>>> make a recommendation out of it) that when voting on a release one doesn't
>>> simply cast a +1 as such.
>>>
>>> I mean, of course a -1 must always be explained, but a +1 should be
>>> explained too, like this:
>>> "+1 Built source on Windows, checked README files, checked ALv2 headers"
>>> "+1 Did only a cursory review but I trust you guys on the code"
>>> and so on.
>>>
>>> Remember, the PPMC is assumed (whether this is written somewhere or not) to
>>> give a +1 based on (mainly) technical reasons; the IPMC will take this for
>>> granted and (broadly speaking) mainly look for compliance issues. If from
>>> the set of PPMC votes the Release Manager can understand, for example, that
>>> no testing at all was done on Linux, he may decide to extend the VOTE until
>>> Linux gets proper coverage; if the PPMC members do not supply this
>>> information, we can't know what was tested and what not.
>>>
>>> So, Jan's question was not for me, but in terms of the "proper technical
>>> review" it would help to see VOTE e-mails more informative than a simple +1,
>>> so that one can be sure that all areas are covered.
>>>
>>> [Feel free to quote/forward this message in public]
>>>
>>> Regards,
>>>  Andrea.
>>
>> This makes me think that perhaps having an official check list to
>> ensure that nothing gets forgotten and to make the splitting of the
>> large task that a release is easy and focus resources more efficiently
>> may be a very useful tool to have.
>>
>> What do other projects do in this regard?
>>
>> G
>> --
>> Visit my Coding Diary: http://gabriela-gibson.blogspot.com/



-- 
Visit my Coding Diary: http://gabriela-gibson.blogspot.com/


Re: Do we have/want a check list for releases?

Posted by Gabriela Gibson <ga...@gmail.com>.
Thanks for the hint Dave, here are the links:

http://incubator.apache.org/guides/releasemanagement.html

http://wiki.apache.org/incubator/ReleaseChecklist

http://incubator.apache.org/guides/release.html

http://wiki.apache.org/incubator/SigningReleases

there are probably more, but I think this is a good start.

I would suggest that everyone has a little bit of a read over the next
two weeks and that we then combine ideas into a 'how to' for the next
release and refine that as we gain more experience.

G

On Mon, Aug 24, 2015 at 2:52 AM, Dave Fisher <da...@comcast.net> wrote:
> Here are two ideas that other projects do.
>
> (1) Have a target in the build or a script that creates all the release artifacts.
>
> (2) include Apache RAT to run license checks  as part of the build.
>
> Look at the emails at the emails from IPMC members on what was done as part of the vote.
>
> Corinthia will certainly have our own unique differences based what artifacts we decide to create.
>
> I think there are probably three check lists.
>
> (1) Release Packaging - what is being released.
>
> (2) Release Manager - how to build, vote and distribute. POI has almost all of this as Ant targets. This can make it easy to for anyone to be RM
>
> (3) Voter - how to check IP from both the ASF requirements and also the project's. We can choose our own standards for quality. The ASF is not concerned if the code works, but the project community does care.
>
> The incubator has wikis with policies and draft policies I would provide the links but I am away from my computer. Perhaps Dennis can provide the links.
>
> Regards,
> Dave
>
> Sent from my iPhone
>
>> On Aug 23, 2015, at 12:37 PM, Gabriela Gibson <ga...@gmail.com> wrote:
>>
>> On Sun, Aug 23, 2015 at 8:18 PM, Andrea Pescetti <pe...@apache.org> wrote:
>>
>> <snipped some complex procedural discussion>
>>
>>> It is not mandatory, but very useful (and I would
>>> make a recommendation out of it) that when voting on a release one doesn't
>>> simply cast a +1 as such.
>>>
>>> I mean, of course a -1 must always be explained, but a +1 should be
>>> explained too, like this:
>>> "+1 Built source on Windows, checked README files, checked ALv2 headers"
>>> "+1 Did only a cursory review but I trust you guys on the code"
>>> and so on.
>>>
>>> Remember, the PPMC is assumed (whether this is written somewhere or not) to
>>> give a +1 based on (mainly) technical reasons; the IPMC will take this for
>>> granted and (broadly speaking) mainly look for compliance issues. If from
>>> the set of PPMC votes the Release Manager can understand, for example, that
>>> no testing at all was done on Linux, he may decide to extend the VOTE until
>>> Linux gets proper coverage; if the PPMC members do not supply this
>>> information, we can't know what was tested and what not.
>>>
>>> So, Jan's question was not for me, but in terms of the "proper technical
>>> review" it would help to see VOTE e-mails more informative than a simple +1,
>>> so that one can be sure that all areas are covered.
>>>
>>> [Feel free to quote/forward this message in public]
>>>
>>> Regards,
>>>  Andrea.
>>
>> This makes me think that perhaps having an official check list to
>> ensure that nothing gets forgotten and to make the splitting of the
>> large task that a release is easy and focus resources more efficiently
>> may be a very useful tool to have.
>>
>> What do other projects do in this regard?
>>
>> G
>> --
>> Visit my Coding Diary: http://gabriela-gibson.blogspot.com/



-- 
Visit my Coding Diary: http://gabriela-gibson.blogspot.com/

Re: Do we have/want a check list for releases?

Posted by Dave Fisher <da...@comcast.net>.
Here are two ideas that other projects do.

(1) Have a target in the build or a script that creates all the release artifacts.

(2) include Apache RAT to run license checks  as part of the build.

Look at the emails at the emails from IPMC members on what was done as part of the vote.

Corinthia will certainly have our own unique differences based what artifacts we decide to create.

I think there are probably three check lists.

(1) Release Packaging - what is being released.

(2) Release Manager - how to build, vote and distribute. POI has almost all of this as Ant targets. This can make it easy to for anyone to be RM

(3) Voter - how to check IP from both the ASF requirements and also the project's. We can choose our own standards for quality. The ASF is not concerned if the code works, but the project community does care.

The incubator has wikis with policies and draft policies I would provide the links but I am away from my computer. Perhaps Dennis can provide the links. 

Regards,
Dave

Sent from my iPhone

> On Aug 23, 2015, at 12:37 PM, Gabriela Gibson <ga...@gmail.com> wrote:
> 
> On Sun, Aug 23, 2015 at 8:18 PM, Andrea Pescetti <pe...@apache.org> wrote:
> 
> <snipped some complex procedural discussion>
> 
>> It is not mandatory, but very useful (and I would
>> make a recommendation out of it) that when voting on a release one doesn't
>> simply cast a +1 as such.
>> 
>> I mean, of course a -1 must always be explained, but a +1 should be
>> explained too, like this:
>> "+1 Built source on Windows, checked README files, checked ALv2 headers"
>> "+1 Did only a cursory review but I trust you guys on the code"
>> and so on.
>> 
>> Remember, the PPMC is assumed (whether this is written somewhere or not) to
>> give a +1 based on (mainly) technical reasons; the IPMC will take this for
>> granted and (broadly speaking) mainly look for compliance issues. If from
>> the set of PPMC votes the Release Manager can understand, for example, that
>> no testing at all was done on Linux, he may decide to extend the VOTE until
>> Linux gets proper coverage; if the PPMC members do not supply this
>> information, we can't know what was tested and what not.
>> 
>> So, Jan's question was not for me, but in terms of the "proper technical
>> review" it would help to see VOTE e-mails more informative than a simple +1,
>> so that one can be sure that all areas are covered.
>> 
>> [Feel free to quote/forward this message in public]
>> 
>> Regards,
>>  Andrea.
> 
> This makes me think that perhaps having an official check list to
> ensure that nothing gets forgotten and to make the splitting of the
> large task that a release is easy and focus resources more efficiently
> may be a very useful tool to have.
> 
> What do other projects do in this regard?
> 
> G
> -- 
> Visit my Coding Diary: http://gabriela-gibson.blogspot.com/