[MCP] First step?

diegogomezdeck at consultar.com diegogomezdeck at consultar.com
Sun Feb 16 10:54:20 UTC 2003

Hi Daniel,

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

We have the same feeling. I't really great to pass from "ideas/opionions"
to "real work" (most of the people only stay on the plane of "ideas").

> From a quick look at the changeset, it touches lots of classes,

yes... it refactor the #initialize method all over the hierarchy.

> and makes a few different kinds of changes,

The needed changes to refactor initialize and some invocations
to 'categorize all uncategorized' option in the method category panel.

> 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 agree on the process. But, imho, this changeset include the minimun
changes for the #initialize refactoring.

> 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.

This is a good idea.  I think we can include more people in this process
(not only "someone from the team").

> 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.

I agree. But I prefer more testing but people not related to the team.

> 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

My idea is:

- Let's take all the steps in "my team" before releasing a changeset to
avoid unnecessary spend of time of everybody. (it includes the first test
realized by the programmer and 1 second testint process by another member
as you describe)
- Publish the changeset for "alpha testers".  WE NEED MORE PEOPLE TESTING.
- Then we can go with the [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.

The idea with the set of SLint rules we're creating it's exactly this.
We'll try to create rules (or tests) for every task we can.

> Let get this show on the road...
> Daniel


Diego Gomez Deck

More information about the Squeak-dev mailing list