[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
|