Diego, remember that you don't have to fix *everything* your changes
break. In fact, it's impossible - you'll never know about all packages
on SM... 

Don't let the removal process stop you or slow you down - what gets
moved to a package will be the problem of it's maintainer (which is why
it's important for such decisions to be widely known). You will have the
stablest process, and the most useful results, if you do your best to
focus on the "framework". 

BTW, the removal of cycles also doesn't have to wait for the removal of
packages - in fact, that's what enable their clean removal. Remember
we're not interested in removals that leave dangling pointers in the
framework, or that require the package to patch the framework when it is
loaded (would be nice if we could make doing that illegal, at least for
packages that claim to applications).

Daniel

diegogomezdeck at consultar.com wrote:
> Daniel,
> 
> > [Vague limits of morphic]
> >
> > two answers -
> > 1. Theoretically, and IMO, and an important part of your job is to
> > bring us there, Morphic, as a framework, should have pretty clear
> > limits. There should be a set of classes that are all needed for a
> > Morphic UI, but don't depend on anything. And everything else is an
> > extension. Obviously applications (Alice Games) are not in. Even Menus,
> > PLMs and friends are probably extensions, in the sense that they don't
> > are not intrinsically needed by morphic (just by many applications).
> > My theory about how to trace and solve this kind of issue is that the
> > unclear borders are marked by cycles - when the framework references
> > applications that use it, that's pathological. So it should be useful
> > to find the cycles and cut them. That's what SpaghettiTracer does. If
> > you want to give it a shot, let me know and I'll explain more.
> 
> This can be done, but we have to wait for all the removals first.
> 
> > 2. On another level (where do your patches go, when you're not changing
> > big structure yourself), you should keep tabs on removals and other
> > ongoing refactorings that have a Morphic aspect (even Celeste, to a
> > small extent), and when you affect something that went into the module,
> > as people have said, send the patches to the maintainers. IOW, try to
> > use the de facto package borders.
> 
> I agree with you that it could be great. But, as you know, these ideas put
> stones in our MCP road.  Each package removal make our work more hard.  Or
> you have something in mind that can help here?
> 
> The less-pain way should have been: First the cleaning and then the
> removals.
> 
> > Daniel
> 
> Diego