[Squeakfoundation] Re: Shrinking alpha image (was Re: Proposal to get to the triad)

[goran.hultgren at bluefish.se]

Doug Way <dway at riskmetrics.com> wrote:
> Well, I think the general idea is that, for each release, we want to 
> come up with a "release plan" containing a small handful of items which 
> we predict will be included in that release.  Maybe we don't exactly 
> need a "release boss" for this.  Maybe a discussion moderator.  Or not.

Well, I want a person. Obviously I struck the wrong chord by writing
"Release Boss" but I simply meant someone that moderates the discussion
and makes sure we get the general plan straight.

And the plan is of course just a plan - the use of it is so that we
hopefully work in the same direction. If we don't then so be it. But
hopefully the chance of us working in the same direction is more likely
if we have a common plan. Right?! And as Doug explains below, the plan
shouldn't typically include stuff that we don't "have" of course.

> The kinds of release plan items I'm thinking of are high-level things 
> like "Removing the Apple fonts from the release" or "Incorporating 
> Anthony's blockclosure work" or "Splitting off 5 to 10 packages from 
> the image".

Exactly. Personally I think it is vital for us to know if we are
adopting Anthony's stuff in 3.6 or later.
We can't just throw it in on a whim.

> We certainly don't want to be in the business of mandating or 
> predicting ahead of time all of the bugfixes and small enhancements 
> which should go in the next release.  Incorporating these will involve 
> using fixed standards for harvesting, and we usually won't be able to 
> predict which fixes will be coming in a future release, so we shouldn't 
> bother including that type of information in a release plan.  Even 
> medium-sized enhancements may not need to be in a plan.  (Depends on 
> what "medium-sized" means, I guess.)

Again, exactly.

> But those high-level items I mentioned above are things which are 
> significant enough that we do need to plan around them to some extent, 
> and they seem appropriate to include in a "release plan".  They'll 

Yes. Exactly. (Hmmm, I am repeating myself here)

> typically be things that other people in the community have already 
> worked on (or are currently working on), where a decision needs to be 
> made whether it should be part of the release.  We can still apply our 
> fixed standards to incorporating these high-level items, but that's not 
> sufficient in and of itself... there should still be some planning 
> involved.
> 
> I guess there are also things that we think someone should tackle, such 
> as cleaning up/replacing the FileDirectory stuff.  I see your point 
> that we should probably not proclaim that this problem will be tackled 
> in the next release, if no work has already been started on it by 
> anyone... rather, we would somehow encourage people in the community to 
> work on it first and then see where things stand.

Yes.

> (You also made some points about the lack of testing of the 3.5 items.  
> Mostly that's a matter of enforcing our fixed harvesting standards 
> (that we're just now coming up with), and having a reasonably long beta 
> cycle (which 3.5 didn't really have, but we should have in the future). 
>    Actually, there were some SUnit tests submitted for the ClassBuilder 
> fix that I verified, but I admit there were none for the project saving 
> bugfix, and to be honest I have no idea if that bug has really been 
> fixed or not.)
> - Doug

regards, Göran