About the MCP page -

You guys've been busy... :-)

That looks like a hefty bit of cleaning work, and also I like how
meticulous you are about automating everything that can be.

Have you guys thought about how to organize your review processes
(including both internal and external people)? I think it's very
important to start it right from the beginning, since it'll help you as
a group consolidate your knowledge, priorities and workflow, and also
because it will enable us Guides to review work that's ready. This
feedback is important to avoid rework and move faster. It might be a
good idea to make the review status visible on the Swiki, by adding a
comment like "reviewed by gm 22/2/03, amended 26/2/03". That way both
you and other people know where you stand.

And as soon as you have stuff reviewed, start sending [FIX]es and
[REFACTOR]es to the list. Yes, I think we need another official prefix
for things that don't change functionality - we want refactorings to be
first class citizens in Squeak.

I agree with what you said in the First Step thread, BTW - you should
solicit external reviewers, as well as internal ones, especially from
the people more familiar with Morphic - they are quite likely to shed
light on things that seemed obscure, whether it's because it's vestigial
stuff that never worked out, or because it's a critical but rarely used
feature.

Daniel

diegogomezdeck at consultar.com wrote:
> Stef, Hannes and list:
> 
> > Hi diego and other cleaners
> >
> > The process sounds really interesting. We were thinking about the same
> >  process with tests on a web page.
> 
> It's comfortable to hear it! thanks.
> 
> > Just a suggestions, have you thought of writing tests that check that
> > the methods you remove will not magically reappear later without been
> > an implicit act.
> > I think that this is an important design decision to remove a method,
> > so we should be able to
> > automatically detect when such method is reintroduced (by another
> > changeset).
> 
> We have a set of tests (using some stuff from the refactoring browser) that
> check for this.  Our idea is to produce 2 sets of tests:
> 
> 1) Set of test that CAN be included in the core. Without dependencies to
> external tools (like RB).  Clear enough to be used as documentation.
> 2) Set of test that CAN'T be included in the core. These tests use some
> stuff from, for example, RB and check for inclusion of already removed
> things.
> 
> > Stef
> >
> > Roel and nathanael have a look at the page:
> 
> Thank you very much! Feel free to modify the swiki page with
> ideas/comments/requests/etc. (Don't forget to say WHO made the
> suggestion).  The url is http://minnow.cc.gatech.edu/squeak/3005 (the other
> link is a mirror made by Markus)
> 
> >> 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.
> 
> Now we're in a first step to clean the "easy things" (most of them are
> warning from SLint rules and other warnings from our new set of SLint
> rules).  After we finish the first step, we'll consider to make "big"
> refactoring.
> 
> Cheers,
> 
> Diego Gomez Deck