Hi Daniel

Thank you for taking your time and for bringing up these important
issues.

Daniel Vainsencher <danielv at netvision.net.il> wrote:
> Consuls/Ceasars, whatever. We very much do need stewards. A lot of the
> point of us being Guides and not SqC II (besides not having available
> the installation disks for the software, nor the hardware.. ;-) is that
> the intention is to decentralize the efforts of moving Squeak forward.

Yes.

> About diplomacy, imperfect English is not a capital crime. Besides, I
> think the facts that the mail was sent to a small forum initially, and
> that it was sent by you - Roel - of all people, show a good effort for
> tact (Sorry Stef ;-).

I agree. As for myself I will try more to come up with a better
experience for the mother-tongue speakers. 


Domain specific stewardship
--------------------------------

> Before I refer to the SCG's idea of taking care of the "kernel", I'd
> like to say we especially will need people able and willing to take
> stewardship of the packages we'll be removing from the image. This is
> because such packages will no longer be part of the Harvesting process.
 
> About the SCG and the kernel - I think you're definitely capable of
> taking care of it, and a well documented tested and maintained kernel
> would be a real asset for Squeak. 

I agree. Berne has the know how. And if something is missing they have 
the time to acquire it (with the help of the members of the list. It
happens
that we have some *very* experienced members who are willing
to answer questions thourougly).


Testing
========

> About the policies you propose - 
> * I agree people should run available tests before reporting a bug.
> * I agree there should be a clear boundary. We should consider using a
> DVS module for it, (which supports class extensions), assuming that
> we're not losing valuable method category information.
> * I agree that the steward should have effective control of his domain.
> This means veto power over changes, as you mention, and also an
> expectation of having his changes accepted within reasonable time.
> Specifically for things that remain part of the image, and specifically
> something as important as the kernel, we'll probably need something more
> like consuls walking together with whoever's Guiding at the time. I also
> agree with Tim's comments, that someone taking this role needs to be
> extra careful about their own changes and involve other people in
> reviewing them.
> * I agree that patches should be tested before submitting to the
> steward. 


Veto power
------------

> * I'd also agree that the steward has to accept or reject, adding that a
> reason for rejecting is also needed.



Bug fixing
------------

> * About the part about bug fixes - I agree that the most reasonable way
> to get a bug report is to get a failing test. However, using tests is
> not so common among Squeakers. And even if it were, we don't want to
> scare beginners out of submitting bug reports. So some active guidance
> would need to complement guidelines (not strict rules) in order to make
> this change effective, but not too painful.
> 
> Before we just ahead of ourselves, what do other people think?
> 
> Daniel



I (Hannes Hirzel) have some additional remarks:

Process
========
I like what you say, Daniel. We will have the same questions with the
inclusion of the Morph Cleaning Projects (MCP) efforts, which
I value very much. In the time the Berne group has been
talking MCP happily has produced an astonishing result.
See: http://www.ira.uka.de/~marcus/swiki/minnow.cc.gatech.edu/squeak/3005.html
Morph Cleaning Project Homepage.

Could somebody rewrite the thoughts outlined above into a
draft for a process description document?


SUnit tests for Class, ClassDescription, Metaclass
=======================================================

Another thing for the group in Berne: I think it would ease
the discussion considerably if you could provide us with
a test suite showing what's is actually broken with #Class,
#ClassDescription, #Metaclass. At the moment we only have
Nathanals proposition that he had some problems filing out
his traits code. Perhaps it is even a small issue which
would be relatively easy to solve for somebody with 
let's say 10 years of Smalltalk experience. Especially
as it seemed to have worked in version 3.2 at the time. 
So I really think we should separate the concern for fixing this
issue and the general setup of the process for further
development. I do not think that coming up with a suite
of let's say the 30 most important tests is a big thing
for two people with LISP experience (one of them having
written a book on Squeak and beeing in the process of
writing another two) and 3 PhD candidates
who use Smalltalk as their primary implementation vehicle.
And you could use these tests in other contexts as well
(read GNU Smalltalk, Visual Works, VisualAge). It is part of 
your job in any case if you really want to do research in
this area.


SUnit tests for getting community acceptance
-----------------------------------------------------
To summarize: I think you would instantly gain
the acceptance of the communty if you write a test suite, 
publish it and say: Hey 10% of the tests do not run
but we badly need the functionality for our research
work. We are going to fix this but we want to have the fixes
included in the kernel.  
(Stephane: Cf. your email to me about using SUnit 
test as a documentation aid)



IMHO I see this discussion linked to another thread:

> A declarative model of Smalltalk
> "Jeff Read" <bitwize at snet.net> wrote:
> When the compiler and parser are tightly integrated with the runtime of the language, instructing 
> the language to add program parts to its currently running program often becomes the norm, 
> rather than crafting everything declaratively in an editor and then running it through a compiler.
> 
> Smalltalk appears to borrow a lot from LISP in this regard, at least in terms of philosophy if not 
> implementation. In Scheme, for instance, the keyword define means "Add this symbol to your 
> currently running global environment, and bind it to the following value..." LISPers tend to see 
> this as an advantage.

Yes this is in fact the case. This explains the interest of former LISPers like Stephane Ducasse and Roel
Wuyts in this issue.

> The difference, if I surmise correctly, is that every Scheme knows what define means; the base semantics 
> for the keyword are standardized -- whereas each Smalltalk has a different protocol for creation of classes 
> and adding methods to them.

To Jeff: Good point. But if you look at the different Lisp implementations / flavours ? Are you sure?


To Berne:
You are not oblidged to ask anybody to come up with a better documented protocol for the creation of
classes and adding methods to them. In fact if the fix is good people will happily accept it. The
only people you have to work with are the stakeholders for the VMs like Tim Rowledge, Yoshiki.Ohshima,
Ian Piumarta, Andreas Raab, Marcus Denker and others in case there are changes for the byte codes
needed. 
A thing we wouldn't like to see is to have a fixed Meta section which needs some additional byte codes 
which are not supported on by all VMs.
And not to forget the work of Anthony Hannan. 


The point of view of an application programmer
----------------------------------------------------------
Generally from an application programmer point of view the whole question discussed here
has not the top-most priority.
If I can still add my classes and methods and have a decent scanner and
compiler I can really subclass to do my own parsers and generators I'm happy. 

> The Smalltalk situation is rather unfortunate, but I see not what having a separate declarative syntax for 
> Smalltalk affords us; with a standardized imperative protocol for creation of classes, methods, and variables, 
> the declarative syntax comes for free.
> 
> -- 
> Jeffrey T. Read



To drive this mail which covers a rather broad field to a conclusion:

What I would like to see is an SUnit test  suite (from Berne?) showing what is wrong with #Class, 
#ClassDescription, #MetaClass and #MethodDictionary at the moment. 

We need executable code to discuss about! 


Regards
Hannes Hirzel