Re: CVS is the `released version'

["Stephen J. Turnbull" <stephen@xemacs.org>]

David Kastrup writes:

 > Please take a look at how the XEmacs package system works.  It has a
 > central repository.  It tends to distribute outdated or non-working
 > code because the people maintaining the central server tend to be not
 > the same creating the packages.

I wish you'd stop generalizing from your experience, which is limited
to AUCTeX and is unrepresentative of the general experience.
Furthermore, your reporting of the features and operation of the
XEmacs package system bears almost no resemblance to the reality.

So let's take a look at how it does work.

In fact, most of our packages (that are not maintained by the GNU
Emacs project) are maintained by their upstream maintainers.  They
generally simply make a commit to the XEmacs CVS repository, which
starts the release process using XEmacs resources, including rolling
and announcing tarballs, a pretest period, and a second announcement
when the pretest is over and the release is promoted to "public
release" (of the XEmacs package).  Only if bugs are reported, or if
the maintainer wishes to give special instructions (eg, more commits
are coming, don't release yet) is there need for anything more than a
cvs commit by upstream.  (AUCTeX differs because for many years its
upstream maintainer has been publicly at odds with the XEmacs project
and has explicitly claimed that the user who has volunteered to
maintain the XEmacs package is unqualified, and thus has forfeited
control over our package to our volunteer.)

Regarding centralization, if you want *us* to distribute packages with
storage and bandwidth contributed to *us* and want *us* to do the work
of rolling the tarballs and so on, then indeed we do insist on
checking in to our CVS.  For almost all changes to packages, it's
simply a matter of copying over the new version to a checked-out
XEmacs tree, and typing "cvs commit -m 'Release of version X.Y.Z.'" in
the package subtree of the XEmacs tree.  This is no different from
getting your package to be released as an official Emacs library,
using GNU resources: you have to check into the GNU CVS repo.

We do insist that "official XEmacs" packages be built in the context
of a full package tree, for precisely the same reasons that GNU Emacs
"wants" to be a monolithic application: Emacs Lisp provides no
facilities for proper modularization (the only namespace is the global
one), and there is no way to achieve inlining (required for Lisp
macros and extremely desirable for defsubsts) from bytecode.

Note that for this reason Tom Tromey's package.el will likely be quite
popular with upstream maintainers, compared to the XEmacs system.
It's Emacs-oriented, so you can assume that the environment will
contain all of the wonderful "stuff" distributed with Emacs.  Most of
the complexity of the XEmacs system derives from the fact that that
assumption is easily violated in a modular package system, while in
practice it won't often be a problem for users of monolithic Emacs.

For end users, in fact, there is no problem with using multiple
package archives.  (Admittedly, I'm personally not at all happy with
our UI for using multiple archives.  But that's an implementation
problem, not a bug in the basic design.)  Nor does the UI make any
attempt to distinguish between mirrors of the "official" archive and
private or upstream project archives.  VM, for example, has maintained
a private archive distributing its "latest and greatest" version as an
XEmacs package for at least 5 years.  Many users use that package in
preference to ours.  Others prefer the convenience of one stop
shopping.

 > If some package is provided upstream, we want to have it directly
 > usable from its default download location.

XEmacs's package system has that feature, and has always had it, by
design.  Cf VM.  There's nothing to stop you from distributing a
package compatible with our download and install UI.  In fact, AUCTeX,
like VM, does.  The VM and AUCTeX sites are not available from the
package configuration menu, but that's only because Kyle doesn't
particularly want the traffic, while there are "personal issues"
involved in the lack of an AUCTeX entry.

However, in the end I have to agree with Richard Stallman.  One big
problem (for GNU) with a package system is that it facilitates
distributed development and permits a general topology (rather than a
star) for the distribution network.  Thus it undermines the incentive
to work in the context of the Emacs project and to assign code to the
FSF.  That's inconsistent with my understanding of the goals of GNU,
and therefore of the Emacs project.

Stefan Monnier is also correct that properly supporting a package
system requires that exported APIs be designated and respected (ie,
backwards compatibility be maintained in the face of clearly better
alternatives).  In XEmacs practice, any API used by a package in the
CVS package repository is exported, unless we've explicitly labelled
it as internal.  In effect, any third party can "out" an API simply by
calling it.  Conflicts are rare, but annoying when they do occur.
This is a perennial complaint of core developers in XEmacs (especially
Ben Wing, but by no means limited to him).  Since GNU wants to
encourage development to happen inside of GNU, not outside of it, it
seems silly to constrain Emacs that way.

I conclude that until distributed development becomes an explicit goal
of the Emacs project, a package system is generally counterproductive
to the objectives it espouses (by which I mean advocating free
software and supporting organizations in the free software movement,
and developing Emacs itself as opposed to third party libraries).