[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS is the `released version'

From: David Kastrup
Subject: Re: CVS is the `released version'
Date: Mon, 21 May 2007 15:51:02 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.51 (gnu/linux)

Richard Stallman <address@hidden> 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.
> You previously explained that this is because making the XEmacs
> package requires doing substantial work on the code.  We are moving
> to reduce to zero the amount of "packaging" required.  All that
> would be necessary is to install the new version in the standard
> repository.  Since this is easy, people would do it often.

If they have access and are interested in doing it.  One of the
package-centric projects I am involved with is TeX.  There is a server
CTAN (comprehensive TeX archive network) which takes contributions in
whatever form people want to make.  There is no really standardized
package format.  A distribution, TeXlive, is usually made yearly, and
it takes a bunch of volunteers to check stuff from CTAN into TeXlive,
update the TPM (TeX package manager files, XML files which basically
say what goes where in the installed tree) and integrate stuff.

CTAN basically places no burden on the submitter at all concerning the
structuring of the package, and licensing (there is a non-free
hierarchy for stuff that can't be redistributed and changed freely) or
copyrights.  Even though contributing to it is basically hassle-free,
it is probably "only" 90% of all interesting packages that are there,
and reasonably up to date.  TeXlive also manages to be mostly up to
date (apart from some oversights).  Contributors are usually asked to
suggest proper installation points in the CTAN hierarchy, as well as
in a running TeX system.

> We could even let the maintainers of the package itself do so.

If we provide Emacs commands that produce a package _and_ can install
into an Emacs CVS work copy (probably generating appropriate ChangeLog
entries semi-automatically) _and_ can install into local directories
for a running Emacs, all from the same package source tree, we
basically are at a point where contributing to Emacs CVS is a
zero-pain procedure once one finished testing and installing locally.
If those commands don't do much more than a recursive copy, so much
the better: it would mean that one could convert one form into a
different one easily, not requiring starting from a "canonical" source

I would guess that such a system would tend to get us more rather than
fewer contributions.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]