Hi all!

Hannes Hirzel hannes.hirzel.squeaklist@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.