proposal for starting work on partitioning

[Daniel Vainsencher]

[apologize if you get this twice, I was having mail problems]

Avi Bryant wrote:

 > I'm a little reluctant to ask for too much outside help until we have
 > a better sense of what the task is, how well the tool support works,
 > what good approaches to the problem are.  I was hoping we would do a
 > reasonable amount of work just with the people on this list first to
 > establish that before begging for more people to get involved.

Definitely understand the sentiment, but I think there's a deeper 
problem here.


 > So let me beg here instead: who is actually interested in doing
 > partitioning work?  Anyone?  Is this just something that we care about
 > more in the abstract than in practice, and nobody really wants it
 > enough to do it?  Are there other ways we should be thinking about
 > this that would get more traction? (like, "how many bits of code can
 > we package up and unload from the image?")

Well, what are our goals? seems to me like the partitioning work is not 
good for itself - it supports (or should support) use cases.

Some obvious kinds of use cases are:
1. "I want to be able to strip my images of this part" (MorphicSplitters)
2. "I want to be able to swap in an alternative implementation" 
(ToolBuilder)
3. "I want to develop/maintain this outside the image" (Celeste, when I 
started doing it)

I, BTW, was under the impression that at least part of our goal here was 
to support the people doing the partitioning, rather than do it 
ourselves (though walking a mile might be a good idea anyway). I'm here 
to do tool support, in and around the MudPie area.

For that we should have "meta" use cases, that are not specific to one 
piece of the image, that should give us extra capabilities towards 
whatever code in the image is well packaged. Some examples. I should be 
able to:
(anyone)
1. See the packages, including dependencies, in the standard browser.
2. Remove packaged code with a click or two.
3. Develop as a package and share my code with no extra hassles (for 
example, starting from a d/led image, I modified PackageInfo. Because I 
didn't declare it as a package at the start, when I saved it, it had no 
parentship information in MC).
(developer affecting code structure)
4. Have tool support when I'm improving my packages internal 
dependencies, and relations with the outside world.
5. Make it really clear when one is working on packaged stuff, versus 
working on the Ball of Mud.
6. Have any improvement/deterioration in the structure of the code in my 
image immediately give the user/community usable feedback, so that 
things move in the right direction henceforth.

So obviously I'm mostly interested in helping concretely with (4-6), and 
think these are important, because until they are in place, things will 
not really improve. But generally:

What usecases (from either of the lists above or otherwise), do people 
on this list want to work on?

Daniel