Hello Craig
Craig Latta craig.latta@netjam.org wrote:
Hi Hannes--
Not having a proper test culture in Squeak leads us to have this kind of funny discussions.
Perhaps you could elaborate as to what you consider a proper
test culture.
An example of an emerging test culture
"Brent Vukmer" bvukmer@blackboard.com wrote: I installed the MetaClassBuilderFix SAR in a 3.4gamma image, installed the ClassBuilder test suite, and then ran the ClassBuilder test suite -- 3 out of 3 tests passed.
Indeed,
Great! You got the message about tests ;-)
Let's move on to the next topic
but to what extent should particular tests delay a particular release? I think that's the main issue here.
thanks,
-C
Excellent question!
IMHO the main issue is that if I look at http://swiki.squeakfoundation.org/squeakfoundation/70
I see the names of the guides: * Doug Way * Daniel Vainsencher * Ned Konz * Craig Latta * Göran Hultgren * Tim Rowledge
Then I click on the link 'Release Plan' (http://swiki.squeakfoundation.org/squeakfoundation/79)
Then I read
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.
------ Now a question everybody who is looking at your work would come up with:
Are these goals met and if yes by which criteria is this evaluated. You have put five points on this list. What do you have to say about them at the end of February?
Postponing an issue is fully a viable option if there are important new reasons coming up. This has to be discussed and communicated.
And: A list of open issues and major known bugs is surely a useful tool for guiding a development process.
I do not see any links on the above mentioned pages.
In the SqC area for various reasons Dan Ingalls used to be the "development process" (chief programmer approach). Because of his long experience he just took care of a lot of things. In the post SqC area the process should be made more explicit. We have all these nice tools and communication aids (mailing lists, Swikis / even world wide phone calls are accessible for many) - why not use them?
I'm hoping that this stimulates you to not soley focus on schedule issues. I really recommend you to (re)read the excellent write-up by Daniel Vainsencher about the nature of releases http://aspn.activestate.com/ASPN/Mail/Message/squeak/1555651 (Email from today).
Regards and happy Squeaking!
Hannes
P.S. My emphasis for having a proper (not perfect!) 3.4 release is motivated by my fears it might be the base for further development for a rather long time. This is fed by the fact that on the release plan (http://swiki.squeakfoundation.org/squeakfoundation/79) there is no single sentence about 3.5 not to speak of 3.6 and 3.7.
Hi all!
Ok, this post is a bit "annoyed" (typing this line in afterwards). Hey, it happens in even the best of families. ;-)
Hannes Hirzel hannes.hirzel.squeaklist@bluewin.ch wrote: [SNIP]
but to what extent should particular tests delay a particular release? I think that's the main issue here.
thanks,
-C
Excellent question!
IMHO the main issue is that if I look at http://swiki.squeakfoundation.org/squeakfoundation/70
I see the names of the guides: * Doug Way * Daniel Vainsencher * Ned Konz * Craig Latta * Göran Hultgren * Tim Rowledge
Then I click on the link 'Release Plan' (http://swiki.squeakfoundation.org/squeakfoundation/79)
Then I read
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.
Now a question everybody who is looking at your work would come up with:
Are these goals met and if yes by which criteria is this evaluated. You have put five points on this list. What do you have to say about them at the end of February?
Well, I think it looks good. :-) Personally I think we aimed to include refactorings that "got finished". I wouldn't characterize them as being the goal though. If that was the case then 3.4 would have taken a loooong time.
Postponing an issue is fully a viable option if there are important new reasons coming up. This has to be discussed and communicated.
And it *is* being discussed all the time.
And: A list of open issues and major known bugs is surely a useful tool for guiding a development process.
Indeed. Would you mind setting one up? I have made offers earlier in this regard but will keep my focus on SM. (Hint: The guides aren't SqC. We are not intended to do the work *for* the community.)
It would of course be good if a bugsystem was integrated in Squeak otherwise it will not be used much I think.
I do not see any links on the above mentioned pages.
But you did see that it said "sketch" at the top I presume?
In the SqC area for various reasons Dan Ingalls used to be the "development process" (chief programmer approach). Because of his long experience he just took care of a lot of things. In the post SqC area the process should be made more explicit. We have all these nice tools and communication aids (mailing lists, Swikis / even world wide phone calls are accessible for many) - why not use them?
We *are* using them. (Getting a bit annoyed here, but I will just count to 10)
(I agree though on making the process more explicit - we are trying hard)
I'm hoping that this stimulates you to not soley focus on schedule issues.
Guess what? This post doesn't stimulate me to do anything at all. Perhaps I am in a bad mood today (didn't think I was because 3.4 just got released but hey) but you are simply just making me annoyed.
I am one of the guides but the whole point with calling us "guides" is because we are *just* that. The intention is that we are all in this together and that we are doing it all because it is fun.
And if you are asking for directions for future releases (3.5 and beyond) - hell, I have a couple of good ideas about 3.5 but that is it. We don't know more than you do and we don't communicate outside of the SqF-list so WYSIWYG.
If you want to hear my ideas about 3.5 then just *ask* me/us.
I really recommend you to (re)read the excellent write-up by Daniel Vainsencher about the nature of releases http://aspn.activestate.com/ASPN/Mail/Message/squeak/1555651 (Email from today).
I have read it, I read everything Daniel writes. It is good as always.
Regards and happy Squeaking!
Hannes
regards, Göran
squeakfoundation@lists.squeakfoundation.org