[Squeakfoundation]Brainstormin'

[Withers, Robert]

Hi Mark,

I suppose I'll join in the discussion, briefly, discussing enhancement
adoption issues, relating to quality. maintenance, and commitment.  Mostly I
lurk on this list, as I feel I can't add much value to the discussion.   I
am excited about where it is going, however.

> -----Original Message-----
> From: squeakfoundation-admin@lists.squeakfoundation.org
> [mailto:squeakfoundation-admin@lists.squeakfoundation.org]On Behalf Of
> Mark Guzdial
> Sent: Tuesday, January 29, 2002 2:50 PM
> To: squeakfoundation@lists.squeakfoundation.org
> Subject: Re: [Squeakfoundation]Brainstormin'
> 
> 
> At 2:25 PM -0800 1/28/02, Dan Ingalls wrote:
> >1.  Decisions about code quality for lots of the stuff that goes 
> >into the system.  This has actually been relaxed a lot in the last 
> >year, as we have let more in through the more SqF-style harvesting 
> >process.
> >
> >2.  Decisions about what should and should not go into the image.
> >
> >3.  Decisions about what Squeak "is" -- what are its strengths, how 
> >it should be "positioned" and presented, who are its likely 
> >customers, and what will make it most immediately appealing and 
> >useful to them.
> 

<snip>

> Bug fixes are easy -- just harvest them and patch them in. 
> Enhancements, especially big ones, need to be made carefully.  I hope 
> that as decisions get made to put new things in, the decisions are 
> made while considering whether we can afford to KEEP the new things 
> in, i.e., is the developer promising to stick around and keep it 
> going.  I don't mean to slight the developers of Linda, Connectors, 
> etc.  I just think that maintaining the enhancement belongs on the 
> decision criteria list.

I totally agree (partially in my de facto role of developer/maintainer of
Linda)

Two quick points I want to make regarding what you have said here.  

First, I believe that a majority of these enhancements will be in the form
of external modules.  While quality and commitment still needs to be high
for these, they don't directly affect the core system, so they can be
managed independently of the core system.  For those enhancements that
extend the core system or that require enhancements to the core system, much
more careful consideration should be given, unless our new module system can
do scoped shape changes of core classes.

Second, the proof is in the pudding, er..the tests.  All enhancements should
come with a robust set of tests for it's features and collaborations.  A
quality test suite is never finished, but continuously evolved and extended.
Requiring a test suite for each enhancement would give the community to rank
the quality of an offering, as well as document the interfaces for
maintenance.  This becomes especially important should owners decide to do
other things with their copious time.

To really make this work, a decision about the fundamental core of the
Squeak should be made and backed up with test cases.  This core has been
identified as including object, blocks, collections, magnitude,
dependencies, multicast events, metaprotocol and classes, and probably a few
others.

Rob