proposal for starting work on partitioning

[John Pfersich]

Gee, didn't they tell you that when you took the job that you could 
only give it up if you died and you still need to give 2 years notice?

>Hi all,
>
>Sorry for being so quiet; I've been extremely busy (in fact, if it
>continues like this, I should probably step down as leader here, since
>it's silly to have a leader who takes a week to answer emails...).
>
>Anyway, comments below...
>
>>  > I see that most of the listed packages have still not been assigned.  I
>>  > wonder if we might have more luck making the initial package list even
>>  > more coarse, and trying to get more than one maintainer for each.  E.g.
>>  > just have one Tools package with a few maintainers, instead of trying
>>  > to find a maintainer each for Tools-Browser, Tools-Changes, etc.
>>
>>  Definitely. And as I have said, people can always divide further later
>>  on.
>
>If that looks like it will work better, great.  We haven't had such a
>rush to sign up for pieces that I feel that list is set in stone;
>Doug, if you have a more granular set of packages in mind, please feel
>free to just change it.
>
>>  > Also, it would probably help a bit to beg on squeak-dev for more
>>  > volunteers. :)
>>
>>  Indeed. But Avi has the ball now. ;)
>
>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.
>
>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?")
>
>>  And I say (yet again) don't get held up in refactoring. Let's just start
>>  pumping out 2-3 PIs so that we get this show on the road.
>
>I don't really know what "pumping out PIs" means, or at least what
>purpose it's supposed to achieve.  It seems to me that something like
>"registering packages on SqueakMap" is much more meaningful, no?
>Which tools (apart from the PackageList that nobody uses for anything,
>and I think we agreed to drop) actually know or care with PackageInfo
>instances exist inside the image?
>
>>  > Basically, I think there is more danger that the effort will stall if a
>>  > private stream is used, because then there will be a big merging effort
>>  > required at the end.  In fact, if everyone can see progress being made
>>  > in the public stream, that might encourage more people to contribute.
>>
>>  Yes, I agree in full. Avi?
>
>Fine with me.
>
>>  > Is there anything else we need to do to help this move forward?  Will
>>  > most of the PI managing/recategorizing be done with the Monticello
>>  > tools?  (We've discussed adding MC to Basic as part of this.)  Also, we
>>  > should add Ned's PI extras to Basic (the 3.9 stream).
>>
>>  I would like to hear Avi's thought on how we handle the PIs, as classes
>>  or instances?
>>  There was a discussion around that earlier, and possibly classes is the
>>  way to go since our main tools (ChangeSets, MC) are centered around
>>  that. But I trust Avi to make that decision.
>
>I don't see a concrete place yet where introducing PI subclasses will
>help with the packaging work, especially given the init script stuff
>that Miso, Ned and I have been kicking around.  So let's stick with
>instances for now.
>
>Avi