Get this party started...

[Avi Bryant]

Hi all,

I thought I'd kick off this mailing list with my (hopefully brief)
thoughts on what our goals and priorities might be; hopefully y'all
will post similarly, and we can start to reach a consensus on what it
is we're trying to do.

On the Teams page at http://anakin.bluefish.se/castaways/6, the
Packages team is described as "Partitioning, PI, packages, TFNR, SM,
Universes etc. Evolving the tools and assigning parts of the 3.9
image, and much more."  So that's our scope.  Personally, I read this
mainly as two interlinked goals:

1. To separate the code currently in the image into discrete sections
with minimal and well understood dependencies on each other.
2. To structure our community so that it's feasible and robust to
manage what Lex talks about as the "commons" of Squeak as many small
pieces of code rather than as one large one.

Note that these are both primarily organizational or social goals
rather than technical ones: the point is to know where the boundaries
between packages are, and to know (as a user) which packages to load
at any given point, not the particular mechanisms that enable this. 
In particular, I'd like to leave discussions about how to represent
individual packages either in the image or on disk to other groups
(like the Modules) group - we have ways to do this already
(PackageInfo, SAR, .mcz), and although they may not be the best ways,
my guess is that they will work as well as any to meet our goals. 
Even if someone does have a reason why a different technical approach
will significantly change the way in which we can organize code, or
make us much more productive in doing so (it's conceivable that MC2
would fit into this category, for example), I suggest that we plan to
continue using the status-quo packaging systems at first: the main
work of defining boundaries should translate easily to any new
technology that comes along, and so we shouldn't sit around waiting
for it.

Where I do think we'll need to develop or advocate new technology is
to better manage packages as groups: the more our world is split into
packages, the more we will need to be able to specify the dependencies
and compatibilities between sets of packages or package versions, and
we don't yet have anything widely used that does this.  With Göran
increasingly busy with other stuff, I don't know how much we should
expect him to do on SqueakMap to address this, but I suspect that one
role of the Packages team will be to slowly take over the maintainance
of that part of Squeak's infrastructure.  We can't ignore the social
component here too: the major thing that SqueakMap has going for it is
how accessible and thus how widely used it is, and we have to make
sure not to jeopardize that.
 
The other major technological and organizational decision I expect
we'll have to make is how to reconcile the update stream with a
packaged image: do we lose the update stream altogether?  Do we make
some updates optional (only applied if package X is loaded)?  How do
we convert from snapshots of package versions to changesets
appropriate for the stream?  And so on.  I don't have any immediate
answers, but there are definitely a lot of questions there.

So a very rough draft of a plan might include:

1. using PackageInfo (and maybe tools like Spaghetti Tracer) to split
the image into minimal dependency chunks, which would allow:
2. for as many packages as possible, unloading them and maintaining
them purely on SqueakMap, which would require:
3. enhancing SqueakMap to model sets of compatible packages, and
dependencies between them, which leaves:
4. for the remaining packages, building technology that lets us
convert between a view of the image as a set of versioned packages
(for developers), and a view of the image as a monolithic application
with incremental updates (for endusers).

Those are the things that come to mind, but these are early thoughts
and I hope and expect to change them once others have posted theirs.

Cheers,
Avi