proposal for starting work on partitioning

Avi Bryant avi.bryant at gmail.com
Sun Mar 6 14:20:18 UTC 2005


Cees and I just chatted on IRC about tools for supporting
partitioning, and coordinating between the package splitting we do and
the work done by the morphic splitters.  Here's the simple proposal I
have to let us get started as quickly as possible, hopefully with
minimal conflict and minimal need for coordination:

- I'll set up a page on the swiki with a list of packages in the image
(if people have string preferences for how granular to make this list,
or what should be on it, please say so).  To begin with they'll all be
up for grabs except the morphic ones.
- If you want to do some work on splitting out a package you put a
note beside it on the wiki saying that you've started working on it
and what the current date is.
- When you've done some work on it and are stopping, post a changeset
with what you've done to the list, and take your name off of the page.
- I'll post the changeset to a special update stream as soon as
possible so that people can easily stay in sync.  Always try to update
from the stream before starting to work on your own splitting.
- If someone's had a package "checked out" for a while without
posting, use your judgement as to whether or not to override their
lock and work on it yourself - maybe email them to see if they'll
release the lock to you, or post to the list about it.

- In terms of how we attack the splitting itself, it seems to me that
it's easiest if people can really just focus on one package at a time
- that is, I want to look through all the methods of a package and
just decide "is it in this package or isn't it".  So I suggest that we
work in two passes: first, we try to kick everything out of packages
that shouldn't be there, by going through all of the classes in the
package and moving any of their methods that shouldn't be in the
package to a special "Orphaned" package.  Second, or in parallel, we
go back through the Orphaned methods and adopt the relevant ones into
our package.  It would be nice if we had some tools to go through
lists of methods in a package, or in Orphaned, with big "Mine" and
"Not Mine" buttons, but we can probably do without that for now.

If this approach seems sensible to people, I'll set up the small bits
of infrastructure required right away.

Avi



More information about the Packages mailing list