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

Doug Way dway at riskmetrics.com
Fri Mar 21 01:41:44 CET 2003

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.

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".

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.)

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

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.

(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

On Thursday, March 20, 2003, at 04:47 PM, Daniel Vainsencher wrote:

> I've said before that I think a "release boss" is either something we
> can't have, or a misnomer. Raising awareness of projects that people 
> are
> starting already is just fine, but IMO, we can't, and shouldn't, do 
> much
> more.
> Let me explain how little is too much - when we posted 3.5a, and
> released it with two fixes that people asked for, that was probably too
> much. Yes, I know I was one of the people for it, but consider this
> consequence - 3.5 is in beta, soon in gamma. Have we heard one voice on
> any squeak list saying "gee guys this actually works"? not that I
> noticed.
> It's already in. The advocates for it have "won". If there's a screw up
> (for example, it clashses with another recent change), we'll find it
> when we're into 3.6. If we don't actually test releases, there's no
> point in having release cycles at all - it just generates fruitless
> discussion. We could for that matter just stop every 300 updates or 3
> months and call it a release, and the name would be worthless.
> I think the solution is a strict "if you want it, you test it" policy.
> Bug fixes don't go into the image unless they're externally tested and
> so forth.
> Heck, adding code that's very broken is much healthier (in alpha phase)
> - at least it's likely to bug enough people that they'll make sure it
> gets fixed (at least while avoiding the "it's so central/complex nobody
> can fix it" syndrome of 3.3 modules).
> Generally, I think we can have either a real policy (fixed standards),
> or a real leadership (human voice telling people what direction to go),
> not both. Since more people in the community already want to pull a
> specific direction, than want to apply specific standards, I think our
> policies and actions as Guides should complement by focusing on setting
> standards.
> If we need to help specific directions materialize, it is more by 
> giving
> direct, quick feedback and help to people that want to do them, than by
> proclaiming it should be done.
> That might just be a bias on my part talking, but it'll definitely 
> color
> what I'm going to focus on.
> Daniel

More information about the Squeakfoundation mailing list