Modules

Doug Way dway at mailcan.com
Sat Feb 26 00:36:47 UTC 2005


On Fri, 25 Feb 2005 10:39:25 +0100 , goran.krampe at bluefish.se said:
> Hi people!
> 
> "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.
> > 
> > This is sort of a special case, since the Kernel is not exactly a
> > "package" which can be loaded, it is the base image.  (Although it could
> > still be defined as a package or module.)
> 
> And thus we should also remember the idea of TFNR - the idea of making
> sure interested and people willing to take responsibility of a certain
> part should be able to do that. In this case there are probably several
> people interested in maintaining Collections - but not the whole kernel!
> 
> So even though I generally agree with the "deployable" attribute, for
> the parts that we typically can't break out yet - staking Collections
> out as a separate "part" (as in part-itioning) from kernel doesn't seem
> to be harmful. It will still be maintained using the update stream.
> 
> Sure we can lump it all together in a huge "kernel" part - and assign 20
> maintainers to it - but will that give the effect we want? The "effect"
> being responsible motivated maintainers tending carfully for these
> classes. I am not sure.

Yeah, there's not really an obvious answer here.  Both aspects are
important.  (Deployability and maintainership.)  In this particular
case, maybe maintainership is the more important aspect.

> > Also, I'm mixing the simple near-term partitioning project with the
> > longer-term modules project here.  (Though it's not *too* long-term as
> > Dan says. :) )  But I think the principles are the same in this case. 
> > Our partitioning should still be roughly based on deployable units.
> 
> "Rougly" yes, but... if this leads to a single "part" (the whole Basic
> image) then there is no point, is there? :)

Yeah. :)  But with most of the rest of the Basic image, the various
parts should be separately deployable (Graphics, MVC, Morphic, etc). 
You could have a headless Kernel (+Collections) without Graphics loaded,
interacting on a command line, and then load Graphics if you wanted.  So
we should still have a number of parts to our Basic image, even if it's
mostly based on deployable units.

- Doug



More information about the Squeak-dev mailing list