[Squeakfoundation]re: release prioritization

[Hannes Hirzel]

Hello Craig


Craig Latta <craig.latta at 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 at 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.