[Squeakfoundation] Re: Shrinking alpha image (was Re: Proposal to
get to the triad)
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
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.)
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
> starting already is just fine, but IMO, we can't, and shouldn't, do
> 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
> 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
> If we need to help specific directions materialize, it is more by
> 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
> what I'm going to focus on.
More information about the Squeakfoundation