"Doug Way" <dway at mailcan.com> wrote:

> Just to throw in a concrete example, Goran & I were casually discussing
> (on a partitioning thread here a month ago) whether Collections should
> be partitioned as a separate PI package from Kernel.  On one hand, you
> might have a separate group of maintainers taking care of Collections,
> versus the Kernel, which makes some sense.  (At least this was the
> initial idea with TFNR.)  But Collections is not at all separately
> deployable from Kernel, the two are very dependent on each other.  I
> think the separate deployability aspect is more important, so I'd favor
> keeping them in the same package.

I snipped the bit where you acknowledged that you're mixing two ideas - 
partitioning for development and partitioning for deployment. It's good 
that we make that distinction, particularly at the beginning since we 
now have lots of stuff that isn't separately deployable, but should be. 
We don't have to wait for separate deployability to divvy up 
maintainership of the image.

However, let's not get too used to doing that. The "separately 
deployable" yardstick is valuable if we stick to it ruthlessly when we 
make partitioning decisions. Your Kernel vs. Collections example is a 
great case in point.  Conceptually they're really quite different, and 
I'd think the "feel" of maintaining them would be different as well. On 
the one hand, you've got really low-level stuff - the machinery of 
executing code in the image, interfacing with the VM, etc. On the other 
hand, you've got a much more abstract library, almost a distillation of 
mathematical concepts. They really *ought* to be separate packages, and 
maintained by separate groups, if only because they'll attract 
different kinds of people to work on them.

If we ruthlessly apply the separately-deployable rule, we may find that 
we'll end up with a Kernel package that includes minimal implementatons 
of a few core collections, and a higher-level package that embellishes 
the kernel collections and provides higher-level collections like 
OrderedCollection, SkipList and so on. There's no need to preserve the 
class categories as they stand today...

Of course, that kind of partitioning may prove difficult, but it will 
probably pay off in the end.

Colin