emacs-devel
[Top][All Lists]
Advanced

[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 12:46:42 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.51 (gnu/linux)

Richard Stallman <address@hidden> writes:

> It seems that part of your motivation for wanting a package system is
> to move Emacs development in a direction that weakens the FSF's
> ability to develop Emacs as an FSF-copyrighted package.
> This confirms my concern about the downside.

I don't think this is a fair characterization.  The idea is not, as
far as I can tell, to reduce the motivation for contributing material
into Emacs' core.  It is to provide a mechanism to work with things
that have no real place in the Emacs core.

In addition, if done right, it could make it _easier_ to pull material
into Emacs' core: right now there are no hard rules for what a Emacs
package (a conglomerate of Lisp files, auxiliary files, documentation
and other stuff) should look like when wanting to get moved into
Emacs.  If there are some policies (like avoiding all absolute paths
or dependencies on the final system) made in connection with a package
system, it could mean that once a decision is made to make a package
an integral part of Emacs (instead of a separately distributed one),
this would be facilitated with a few commands and a commit.

Also, such a system could replace the vacuum that has called into
being the Debian Emacs packaging guidelines, which are not understood
by pretty much every Emacs and XEmacs developer, and not by all too
many Debian developers either.

I can't see how this would in any way diminuish the FSF's ability to
develop Emacs as an FSF-copyrighted package.  At the current point of
time, both pulling a (non-standardized) package into Emacs and
maintaining it externally is a source of pain.  A minimal package
system (which would probably consist more of structuring policies
rather than actual code implementing it) would reduce the pain on
either level.

-- 
David Kastrup




reply via email to

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