Hey Diego, MCP team, good to see your first steps in this project. 

>From a quick look at the changeset, it touches lots of classes, and
makes a few different kinds of changes, which makes it a not-so-easy to
review and integrate changeset. Which is good, because it forces us to
test the process we need to get these things accepted anyway.

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.

Let get this show on the road...

Daniel


diegogomezdeck at consultar.com wrote:
> German and list,
> 
> I just uploaded the first (of many to come) changeset with the first
> cleanning.  It's called CMP-initialize-dgd-2003.14.1.cs.gz and it's at
> http://minnow.cc.gatech.edu/squeak/3005 (as usual).
> 
> Time to drink champagne!   Ok.. you're right, let's wait for some testing
> before.
> 
> TIME TO TEST!!!
> 
> Cheers,
> 
> Diego Gomez Deck
> 
> 
> > Hi everybody,
> >
> > After some people looked inside Morph and subclasses it seems that
> > there are lots of code to fix just using SLint (I've also made some
> > specific extensions to SLint).
> >
> > I consider this a good first step, after which we can come up with
> > surely harmless fixes. This will give us a more consistent code for
> > further refactoring and clean up.
> >
> > So, if you want to take a look at Morph and allSubclasses, or have seen
> > before "offending" code that is crying to be rewritten, please report
> > it here: http://minnow.cc.gatech.edu/squeak/3005.
> >
> > Or give your ideas if you don't agree, of course.
> >
> > May the Force be with you,
> >
> > German Morales