[squeak-dev] 4.1 release tasks
laza at blobworks.com
Fri Mar 19 08:21:59 UTC 2010
In my view the job of the SOB is not to do micromanagement.
So how to track issues, that should be handled before releasing 4.1,
would be to decide by the release manager for 4.1.
I don't think that there is any harm done by my suggestion how this
could be done and not even by actually laying the grounds for this way
by creating an issue on mantis. If the release manager decides to do
it some other way it shouldn't be to hard to switch to that procedure.
And actually doing things provides a playground for decisions.
Decisions that I think should be made by the SOB are at least if 4.1
should be a "quick" release or not and the requirements for a
successful release. In my view this has been done already.
It would be fortunate if the SOB could explicitly name a manager for
the release and that both agree on goals, requirements and a
timeframe. Then the release manager could form a team and start
working without too much interference by the SOB.
Maybe we just have to wait after the constitutive meeting of the new SOB.
On Fri, Mar 19, 2010 at 02:31, Ken G. Brown <kbrown at mac.com> wrote:
> I think this deserves to be documented as a proposal, as is the normal requirement by the SOB and placed somewhere officially as a permanent record.
> When this proposal has been accepted by the SOB this should be noted there as well.
> Ken G. Brown
> At 8:28 PM -0700 3/17/10, Andreas Raab apparently wrote:
>>As stated in the previous message, here is a thread to gather release tasks and the time frame in which they should be addressed. I'm taking the "4 weeks to release" rather literally below because I want to avoid excessive discussions about what we should do with feature x or y. Rather, I'm saying let's ship it as it is, get it out quickly, and spend our time moving forward from there. With that said, here we go:
>>[ ] Build a 4.1alpha trunk image
>>What: We need to re-apply all the changes that went into trunk on top of 4.0 to create a proper 4.1 alpha. I'm planning to do this by the weekend and remove the previous trunk images since they're now obsolete.
>>When: March 20th
>>[ ] Feature Freeze trunk
>>What: Feature freeze the trunk. Only fixes for identified issues go in.
>>Who: All core-devs.
>>When: March 28th
>>(this gives us one more week if you have anything that you feel strongly about)
>>[ ] Make tests green
>>What: Review all the tests on all platform; identify failing tests, make them pass or document known failures.
>>When: April 4th (this is a bit of wishful thinking...)
>>[ ] Ensure current VMs
>>What: Ensure that all platforms have current VMs available, with all required fixes applied.
>>Who: VM maintainers
>>When: April 4th
>>[ ] Create a 4.1 release repository on source.squeak.org
>>What: Create a release repository that we can point the release image to for subsequent 4.1 maintenance updates.
>>Who: Any source.squeak.org admin
>>[ ] Identify Mantis bugs that should be in 4.1
>>What: Categorize bugs that need to be looked at for the 4.1 release (does NOT imply fixing the bugs)
>>When: April 4th.
>>[ ] Build release candidates
>>What: Start building release candidates to ensure we have a process. Casey probably still has a few make files around.
>>[ ] Write welcome message, press release
>>What: Write a welcome message, overview of changes, press release etc.
>>When: April 4th.
>>As a time line we get:
>>- Create 4.1 release repository
>>- Build a 4.1alpha trunk image
>>- Feature Freeze
>>- RC1 build
>>- Green tests
>>- Updated VMs
>>- Mantis bugs organized
>>- Welcome message, press release
>>- RC2 build
>>- All bugs fixed (yeah, right :-)
>>- RC3 build
>>- Ship date
>>This is obviously a tight schedule but if we want to get the puppy out in four weeks we need to get schtuff done. I don't think it's unreasonable though; all the tasks are doable on their own, we just need a few people to step up and pick one they can help with.
>> - Andreas
More information about the Squeak-dev