I have just tried to use the refactoring browser ... got a walkback 
that I couldn't understand ... went to my email archives to see if 
there is a newer version ... read the discussion between DanielV and 
Stéphane about the right way to maintain it ... and am left feeling 
rather unhappy.

As I understand it, the current state is that the "official" 
distrbution is known not to work, but that

Daniel is right, I think, that the RB is too complex just to be 
treated as a goodie and left to take care of itself.  Last fall 
Nathaniel and myself spent about three days trying (and failing) to 
track down what we thought would be a simple bug in the abstract 
instance variable refactoring -- and Nathaniel is really good at this 
stuff!  In the end, he decided that it was simpler to start from the 
parser in the compiler to implement this particular refactoring than 
to track down the bug.

For those who have not looked at RB, there are two main parts, in 
addition to the UI:  a parser that matches patterns like '`@method: 
`@Args ^super `@method: `@Args' and a set of definitions of the 
various refactorings in terms of the parser patterns.  So, when 
something does not work in the expected way, it is hard for the 
uninitiated tell which part is going wrong, and therefor which part 
to fix; "fixing" the wrong part would indeed rapidly lead to code rot.

So I agree with Daniel's posting: RB needs someone who understands 
the framework to coordinate the process of debugging it and 
maintaining it.

The reason that I'm unhappy is that no one has stepped forward.  We 
all have our real work to do, I suppose.   And yet: here is a GOOD 
IDEA (refactoring) that has been invented by the Smalltalk community 
and from which all of our code would benefit ...

What can be done?  I think that making RB depend on stable 
DeltaModules might be Error 33...

	Andrew