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
|