Re: CVS is the `released version'

[David Kastrup]

Ryan Yeske <address@hidden> writes:

>    I wish that were true, but most of the work of installing a package
>    system is making everything _use_ it.
>
> There are many people who are not necessarily emacs lisp hackers but
> would be willing and able to prepare third party elisp packages from
> existing sources.

This statement is in stark contrast to my personal experiences.  The
AUCTeX package, a pretty important editing mode for TeX-based formats,
has been lagging behind seriously in the XEmacs package system for the
last five years or so.  While a single person finally was found who
would _try_ keeping it more or less up to date, this has not really
worked out reasonably well.  As a result, the current version as
distributed by XEmacs remains terribly outdated.

The XEmacs package system basically consists of several pieces of
policy: a package layout which packages have to obey, a central
package repository where packages are checked in via CVS and built,
servers populated from this repository and mirrored.

AUCTeX is a complex package interacting with quite a few external
components.  It has an autoconf-based build procedure that can cater
for a lot of constellations and can be employed to tailor-fit AUCTeX
to a particular TeX environment.  It also runs on several different
Emacs variants.

The build infrastructure of AUCTeX is flexible enough to create an
XEmacs package, and indeed we distribute ready-built packages from the
AUCTeX download area.

XEmacs policies, however, prohibit the distribution of packages not
built with the XEmacs-specific build tools.

So basically the third-party maintainer has the grateful task of
taking the AUCTeX source package, rip Makefile and other generic build
structure from it, add definition files and stuff for the XEmacs
package build process and massage them until the output is just like
what AUCTeX upstream distributes as an XEmacs package in the first
place.

> I believe that the various free operating system projects are able
> to find the resources for similar work for their package management
> systems without draining the resources of the hackers actually
> working on the development of the packages themselves.

Please don't make the mistake of comparing the developer numbers on
operating system packagers (and the amount of work done) with those on
Emacs.

Most free operating systems which are not just packaging of other's
technology have one active work area: the packaging infrastructure.

In contrast, we Emacs hackers actually mostly work _coding_ stuff, not
arranging it.  And still our manpower is quite less.

Now the theory might be that once packaging becomes the mot du jour,
lots of non-developers will package lots of great things.

The problem is that there are not that many great things around that
are not already integrated into Emacs.

So a package system that comes with lots and rules and policies like
the XEmacs system does, is rather something that blocks inclusion of
good code and/or leads to its bit rot.

We would not want to go down the same path.  This does not rule out
package systems per se, but they are certainly not the panacea that
can offset bit rot, overpolicing and general indifference.  For
AUCTeX, the XEmacs package system has shown to be a roadblock for
getting uptodate packages to the users.  Not because of the structure
of such a package (which is a tar.gz file organized to drop into the
XEmacs package tree, with few additional files in fixed relative
places, like one defining package version and identification, one
containing customizable variables so that you don't need to preload
the package in order to customize it, one containing the autoloads,
one containing a list of all files so that the package can be removed
again if necessary, and some files like info files that are dropped in
standard places): that is actually useful.

But the whole _mandatory_ infrastructure (only available via anonymous
CVS and not conducive for creating Emacs packages) which one _has_ to
employ to create such a package (which has to be checked _into_ CVS so
that this venue is only open to registered XEmacs developers) so that
it will be accepted for distribution by the central servers (there is
no such thing as package specific repositories) is not really
conducive to producing output unless one is quite dedicated to XEmacs
specific development.

With all that policing, the administrative burden is actually more
than getting some Lisp file accepted into the Emacs core tree.

The advantage is just one of decoupled updates of centrally organized
packages to the centrally organized core.

I doubt that this could not equally well be achieved with a policy of
more frequent releases from a release branch.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum