+1.

On 3/10/10 8:58 AM, Andreas Raab wrote:
> I think that's exactly right. Perhaps we should formulate the tasks for
> a release more clearly. Here's an attempt at doing this:
>
> Release Tasks:
> * Drive the process to decide which packages to include besides the core
> packages. This needs to be a community process where the community
> decides what should be in Squeak and what shouldn't. The release team's
> task is to implement the results of this discussion.
>
> * Drive the process about what the out-of-the-box look should be. Which
> projects should be loaded by default, what they should contain, how the
> preferences should be set, etc.
>
> * Ensure that important bugs are closed for the new release, solicit
> feedback on the missing issues, decide what are considered release blockers.
>
> * Ensure all tests are green.
>
> * Ensure proper packaging of the result on all platforms, verify
> installation procedures, find a variety of testers for the result.
>
> * Ship it.
>
> Am I missing something?

Yes, I think these things also should happen in some shape or form:

* Update web presence and docs. This includes ensuring that
   latest packages are properly linked and downloadable;
   all "official" web pages are updated to reflect current status;
   release notes are available; #squeak topic is updated.
   This should be live before announcements go out.

* Announce the release. This includes preparing one or more official
   release announcements (eg full and short version), with
   sufficient community preview and refinement; identifying suitable places
   to announce; posting the announcement to those places at the right time.

* Release followup. This includes watching replies to the announcement,
   and release-related queries on irc and squeak lists, and when appropriate:
   following up with public replies, forwarding problems to the appropriate place,
   and generally helping ensure the release is a successful one, up to
   and including making follow-up releases to fix critical issues.


"Releasing is always four times as much work as you think"