Okay, here's my package system proposal.  It's key advantage is that
it's basically implemented already--we just need to set some
conventions.  The core idea is obvious from the name: use changesets as
packages.

To defend the idea a moment before going into particulars, please note
that several packages *are* already successfully distributed as
changesets.  OSProcess is a notable example, and MPEGPlugin was one for
a while.  Some people load OSProcess, and others don't -- it's really
quite easy.

Furthermore, again before discussing particulars, please note that
mostly we need not just a package system, but actual packages.  No
package system is really going to divide Wonderland into its own
package.  Someone, or more reasonably some people, are simply going to
have to huff through the core image and divide things out.  This is not
fun, but the existing discard* methods ought to help -- just file things
out before they are actually discarded.

Finally, no reasonable package system is going to keep a change in
one package from breaking another package.  This really just depends
on care by the package authors.


On to particulars.

First, someone needs to maintain the changeset for each package.  This
is good for any packaging system, but it might not be obvious with my
simple one here, and so I mention it explicitly.  That maintainer will
take care of making releases, merging patches, making announcements, and
all the other boring crud that goes along with making something of a
product out of a toy.

The maintainer needs a way to distribute versions of the package as
updates are received.  A Swiki page would be quite reasonable; simply
link the page from the All Projects page.  In fact, the current
changeset could be linked directly from All Projects.  With some simple
conventions, one could even write a package browser that scanned the
swiki.

Packages should list their prerequisites.  They can do this simply as a
comment in the changeset header.  So far, most packages don't have very
complicated prerequisites, and so this manual management should be
sufficient for now.  It can be automated later, so long as we pick a
fixed syntax for the Requires: (or whatever) header.


People need a way to submit changes to a package.  If the changeset has
a Maintainer: as well as an Author:, then it is simple to email patches
directly the current Maintainer: listed in the header.  A little bit of
code in ChangeSorter can make this very smooth, but it's not that much
trouble even as it is.

It would be nice to have namespaces.  However, we don't *have* to have
them immediately -- I'd be very happy to have packages one way or the
other, and I think most others here would be, as well.  Furthermore,
namespaces can be easily added to the fileout format, by simply adding a
new directive that sets the current namespace.

Okay, that's all that comes to mind immediately.  If we just assign
someone to be responsible for each package, e.g. by adding a Maintainer:
tag to each package, then I think we can work out the rest of the
details as we go along.

Overall, it would be very nice to have a good package system.  But even
more than a good package system, it would be nice to have some good
packages.


Lex