proposal for starting work on partitioning
jp1660 at att.net
Sun Apr 3 19:19:42 UTC 2005
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?
>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
>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.
More information about the Packages