Daniel Vainsencher wrote:
I agree that we should make sure removal of a package doesn't break either it or other stuff in the image.
I don't know whether there's a point in separating the refactorings from the removal package. After all, the removal package is supposed to get rolled into the updatestream.
The Celeste removal does the refactorings required and then removes the package, which seemed reasonable to me at the time. If someone thinks this is a problem, I don't mind reworking it so refactorings and removals are separate.
Actually, that's not a big deal... for some reason I was thinking that we were encouraging separate refactoring packages.
I guess the more important thing is that we should encourange the resulting maintained packages to not overwrite methods if possible. This will mean that the pre-removal refactoring did its job. In practice, though, this may not always be possible.
Other quality criteria - we should encourage package maintainers to never override code, but we can't enforce it. Right now, there isn't even a warning when loading a package that overrides code. We should provide the tool support first, start pushin the rule later.
Right. By tool support, you mean things like adding the warning?
- Doug