Hi Alex, SCG, I'm glad you did decide to take this role, and start the
KCP.

I think these sort of focus, group projects can be a very good thing for
Squeak, in that they can create a good process locally, and let more
people participate, and spread all sorts of knowledge among their
members.

And with good integration with the overall process, they can help
improve our "visibility" and "speed". By visibility I mean that everyone
knows what progress has been made, for each package, how it is regarded,
and how close/far it is from being accepted. By speed, I mean getting
more enhancements generated, with more of them accepted with fewer,
faster cycles.

I think these projects help because they set their standards internally
(use SLint, use RB), list their specific goals in their specific domain,
for the community they serve as a source of focus on a subject (if I
think something is wrong with the kernel, I know who to propose the
change to), and for us Guides it should provide a single point of
contact to "negotiate" strategy with.

When the MCP started, I posted a mail to provide guidelines on how to
most effectively get the process started, which I think apply here too.
The important part is the results - tested, documented changes, in small
bites, that have had more than two pairs of eyes review them. Do you
agree these apply to your project?

Daniel

**************************************************

I propose you get someone from the team to review your changes, first to
see if they have improvements, and also to document them (as you did)
making sure to explain why every kind of change done is acceptable (for
example, "refactored #initialize" -> "replaced assignments to color with
implementations of defaultColor, and..."). This stage makes it much
easier for us to accept what you did, but also documents the insights
you've had. Also make a list of affected subsystems. Creating these
detailed summaries will help the knowledge spread around.

If the changes included several unrelated kinds of changes, it's better
to split it into several changesets, each with it's own documentation.

Then comes testing. Take the subsystem list produced above, and have
someone test each one, and document that it's fine (so you can make sure
you've tested everything). The test doesn't have to be a complete stress
test - but it has to check the aspects affected by the changes made.
Changed how the colors get assigned? bring it up and make sure it looks
right. Other changes might require using the system in the appropriate
way. It's important that someone other than the author do the testing,
and that they actually exercise the changed code.

When it's reviewed and tested, make it an ENH, and include all the above
information, and everyone that touched it.

To summarize:
* Make CS.
* Review (what was changed, why, what's affected)
* Split if needed.
* Test (everything affected, according to specific changes)
* Post as ENH

BTW, as Stef says, sometimes the best documentation is a test. For
example, if you find that Morphs should never assign to color in
initialize, because that's actually ignoring the frameworks way of
setting colors, make a SUnit test (in this case, maybe using SLint rules
like GermanM's). That way next time it will be caught earlier.
**************************************************

Alexandre Bergel <bergel at iam.unibe.ch> wrote:
> > Software Composition Group guys, does one of you want to be the
> > maintainer?
> 
> The SCG group in Bern proposes to the community to be maintainer of 
> this set of classes. As direct responsible, I propose myself (Alexandre 
> Bergel).
> 
> The first steps would be:
>    - to set up a web site as it exists for the Morphic Cleaning Project 
> (MCP: http://minnow.cc.gatech.edu/squeak/3005)
>    - to extend the unit tests that exist (thanks Andreas) with new ones 
> covering the rest of the functionality
>    - to precisely identify issues and how to correct them
>    - to maintain a list of fixes (the ClassBuilder one proposed by 
> Andreas will be one of these)
>     - to be responsible for including changes from other people, fix 
> bugs identified by people
>     - to decide what gets in a release and what does not.
> 
> If this proposition is accepted by the community, the basic 
> infrastructure will be set up as soon as possible, and a mail describing some issues will be sent soon.
> 
> We invite everybody competent to join. Noury, we want you :)
> 
> 
> Cheers,
> Guy at Bern
> 
> > 
> > -----Original Message-----
> > From: Andreas Raab [mailto:andreas.raab at gmx.de]
> > Sent: Friday, February 28, 2003 10:49 AM
> > To: 'The general-purpose Squeak developers list'
> > Subject: RE: ClassBuilder fix, SqueakMap, and releasing 3.4
> > 
> > 
> > Brent,
> > 
> > I would appreciate if you could take me out as the "maintainer" at
> > SqueakMap. I'm not going to maintain any of this in honest. If you'd
> > like to
> > be the maintainer of a suite of tests for ClassBuilder feel free to add
> > yourself.
> > 
> > Cheers,
> >   - Andreas
> > 
> > > -----Original Message-----
> > > From: squeak-dev-bounces at lists.squeakfoundation.org 
> > > [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> > > Behalf Of Brent Vukmer
> > > Sent: Friday, February 28, 2003 2:40 PM
> > > To: The general-purpose Squeak developers list
> > > Subject: RE: ClassBuilder fix, SqueakMap, and releasing 3.4
> > > 
> > > 
> > > BTW, 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.
> > > 
> > > -----Original Message-----
> > > From: Brent Vukmer 
> > > Sent: Friday, February 28, 2003 8:32 AM
> > > To: Squeak-Dev (E-mail)
> > > Subject: ClassBuilder fix, SqueakMap, and releasing 3.4
> > > 
> > > 
> > > Andreas's fix for the ClassBuilder bug is now on SqueakMap.  
> > > So is the suite of unit tests that Andreas created to test 
> > > ClassBuilder.  
> > > 
> > > On the docs side, I've created the following chain of Swiki pages: 
> > > "Documentation"->"Known Bugs"->"Known Bugs in 3.4"->"Adding 
> > > instVar to ClassDescription breaks ClassBuilder"
> > > 
> > > We have SqueakMap fix-love and Swiki documentation-love for 
> > > the bug.  Let's roll with the 3.4 release.
> > > 
> > > Cheers,
> > > Brent
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> 
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Bergel Alexandre  http://www.iam.unibe.ch/~bergel
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.