[Squeakfoundation]re: release prioritization (was "ClassBuilder problem")

[goran.hultgren at bluefish.se]

Hi all!

Hannes Hirzel <hannes.hirzel.squeaklist at bluewin.ch> wrote:
[SNIP]
> >From http://swiki.squeakfoundation.org/squeakfoundation/79
> <citation>
>  3.4 -- The main purpose of this release is to create an up to date,
> viable version, that's a good starting point to making Squeak more
> modular and it's development more decentralized.
> 
> Changes:
> - Includes non-modules related updates from 3.3a, including the dynamic
> filelist services refactoring.
> - An option to load the SqueakMap package catalog and the base Package
> Loader from the net.
> - A dynamic open menu so packages can now register there and become
> first class applications.
> - Refactorings making various parts of the image easily removable. See
> Modularizing the Squeak image for the plan and status.
> - Various other fixes have been included.
> 
> Release is tentatively set to end of 2002. 
> </citation>
> 
> 
> Regarding "Refactoring making various packages easily removable":
> 
> There is just Balloon3DRemoval and GamesRemoval. I do not consider this
> goal is met.

Well, I think the goal there was to simply include those refactorings
that we got around to do.
Then later (I think) these refactorings instead got registered at SM and
we decided that actually performing them could wait for 3.5 - otherwise
we are potentially prolonging the relase by creating turmoil in the
image.

So... well, we can all argue about that goal - but personally I think it
was good that we didn't start to actually tear the image apart in 3.4
because I think it will be *hard work* and take *solid time and
commitment* to get it right. Lets do that in 3.5 now that we have a 3.4
that seems pretty good and has SM enabled from start. Newbies will
hopefully read the welcome text and find the link.

(and the fact that we intend to start breaking apart the image makes me
wonder if we can aim for a one-month release cycle as well - sounds darn
impossible to me)

> And breaking an important thing and not including the fix is surely not
> good stewardship as well.

And Hannes also wrote in another post:
> Well of course you guides can do anything you want "releasing" things,
> i.e. putting a label on a jar and call it a "release". Not having a
> proper test culture in Squeak leads us to have this kind of funny discussions.
> Measuring risk just with a feeling in the  guts? "I feel like
> releaseing...
> I'm scary of metaclasses ....people don't use them anyway...".

Hey, hold on a minute. I usually don't get upset but the above felt like
a blow below the belt.
Fact: We don't have a good test culture in Squeak yet.

Does this mean we should just give up? Of course not - we try to make it
work. There is something called alpha, beta, gamma which we try to use
and sure - it's not as cool as 14000 unit tests, I agree.

Does it mean we don't want a good test culture? NO. We all want it
(well, of course someone raises his hand at this point and says "I
don't" but whatever) and we are slowly moving into a module world where
tests will probably play a significant role in the future - *when they
have been written*.

It's life, things break. IMHO. Sure, if we had tons of tests etc etc it
wouldn't happen - but we don't yet.

Sidenote: Personally I am just thankful Doug and Scott have had the time
to push this release through.

> Again: Where does this time pressure at the expense of quality come
> from? 

Well, there is pressure within the community to get 3.4 "nailed down" so
that people can start depending on it for their work. That is the only
pressure I am aware of but it is enough. Of course there is no pressure
from outside the community (as with most open source projects) - we
simply create the pressure ourselves.

IMHO it is all about setting a level of quality and then trying to reach
it within a reasonable time limit. If we are aiming for a perfect Squeak
then we would never be able to release because FIXes just keep
appearing... Thankfully. :-)

Anyway, I am also not sure we should be discussing an elaborate release
process until we know a bit more about how the future will look. Why?
Because the process should be anchored in packages and not the "old" way
of viewing the Squeak cosmos (the image). Packages can have clearly
separate life cycles and release processes - that is one of the big
points.

So I am a bit amazed that noone picked up the thread about that,
subjects:
"Package grouping (was SqueakMap vs Debian)"
"SqueakMap vs Debian"

So, please read those posts and apply your thoughts about a good release
process using tests on that kind of Debianish world. That is at least
what I would like to discuss.

regards, Göran

PS. I think it is imperative that we maintain the focus on packages and
distribution of maintenance responsibility of the core packages
(stewardship). The centralized approach simply doesn't scale enough.