[squeak-dev] Re: I wish retake old good practice

Andreas Raab andreas.raab at gmx.de
Wed Mar 10 16:58:24 UTC 2010


On 3/10/2010 6:07 AM, Bert Freudenberg wrote:
> On 10.03.2010, at 12:34, keith wrote:
>>
>> it was the decision that was made after the 3.9 arguments that caused the 3.9 team so much pain.
>
> The 3.9 aftermath was not nice and I regret the pain it caused. But the root problem was that Marcus and Stef had to do way too much on their own. No release team should ever have to do that much work again. What they did was heroic and I'm still thankful for that, but it was not sustainable.

Completely agree.

> That's why we needed a new process where people could contribute directly, and we hopefully now found one with the Trunk contribution process.
> That's also why I'm advocating against a release team that does anything more than actually package a release.
> And that's why I'm arguing for a freeze period on Trunk when we near a release to let the dust settle, so effectively *everybody* is working towards the release, and not just one or two people.

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?

Cheers,
   - Andreas



More information about the Squeak-dev mailing list