Roel Wuyts roel.wuyts@iam.unibe.ch wrote:
Somebody needs to decide what is a release and what's get in there, and it was decided that these were the Guides. I trust them to do an excellent job at this, that is why they are responsible. I can imagine that there is some 'bigger plan' for which they want to have this release. The question for me is: 'what is this bigger plan'. If it is only that it was promised to have a new release by a certain time, then I agree with you that we can wait. But I guess the plan for 3.4 was to have SM up and running, and that is also important to get out so that everybody can enjoy it.
Yes, adding SM and not breaking existing things.
<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.
And breaking an important thing and not including the fix is surely not good stewardship as well.
Again: Where does this time pressure at the expense of quality come from?
Cheers Hannes
On Fri, Feb 28, 2003 at 11:22:04AM +0100, Hannes Hirzel wrote:
Regarding "Refactoring making various packages easily removable":
There is just Balloon3DRemoval and GamesRemoval. I do not consider this goal is met.
I really don't think anyone intended to start this kind of refactoring in 3.4: This is nothing you want to do in a beta stage! Refactoring and cleaning is something for 3.5alpha.
But I think it would be good to have a last look at important bugfixes to add to 3.4, though.
Marcus
On Fri, Feb 28, 2003 at 11:22:04AM +0100, Hannes Hirzel wrote:
Again: Where does this time pressure at the expense of quality come from?
I've been watching this discussion with interest. I think that the Guides are showing a strong regard for quality, and are doing their best to make good decisions in the release process. They are trying to balance risk versus benefit from the the perspective of the customer, and they are remembering to pay attention to the question "who is our customer." This is not easy work.
The process is being handled very well in my opinion, so I want to add a word of support and thanks to the Guides. Carry on!
Dave
Hi all!
Hannes Hirzel hannes.hirzel.squeaklist@bluewin.ch wrote: [SNIP]
<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.
squeakfoundation@lists.squeakfoundation.org
-
David T. Lewis -
goran.hultgren＠bluefish.se -
Hannes Hirzel -
Marcus Denker