[Top][All Lists]

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

Re: async 1.0

From: Bastien
Subject: Re: async 1.0
Date: Sun, 24 Jun 2012 17:42:44 +0200
User-agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.1.50 (gnu/linux)

Hi Christopher,

Christopher Schmidt <address@hidden> writes:

> I think every single package that is not absolutely
> necessary for running a bare Emacs should be moved to GNU ELPA.  In
> particular I am thinking of packages like CEDET, Calc, Calendar, ECB,
> ERC, Gnus, Org-mode, all prog-modes, eshell, mh-e, rmail, shell, term
> etc.  

I disagree.

As Eli said, this is just some additional MO in GNU Emacs.
Moreover, there is no useless burden when launching Emacs.
If there is, that can be fixed without removing stuff.

I'm fine with the current policy for GNU Emacs and GNU ELPA,
as they complete each other in a useful way: a light-weight
policy for GNU ELPA ("from FSF-copyrighted authors") and a
strong policy for Emacs ("be accepted by Emacs maintainers.")

By moving stuff to GNU ELPA, you will not only decentralize
maintainance (it is already decentralized for many packages),
you will also remove the pride of "being part of GNU Emacs".  
If you want people to be pride of "being part of GNU ELPA", 
then you will have to define a stronger policy for GNU ELPA.  
And you will end up with more work, as you'll now have two
things to maintain.

(Also, I think it's good for a package to have two categories
of users: regular users that use the package from GNU Emacs,
and power users that want to test the latest versions.  Telling 
people to use the constantly updated version from GNU ELPA will 
make your userbase perhaps too homogeneous.)

> On top of that, IMO every single core package should have a copy
> on GNU ELPA so one can to overwrite the native GNU Emacs one with the
> one from GNU ELPA.  

At least for Org-mode, this is already the case.

> This would decouple all packages from the Emacs
> release cycle and allow bug fixes to be distributed instantly.  On top
> of that, this would make actual core emacs development, test, release
> and bug management a lot easier.[1]

There is Elisp code everywhere on the web, emacswiki, etc.  It *is* 
pretty chaotic and creative.  Having many useful packages included
in GNU Emacs helps users to find some order in this chaos, and my
guess is that it's part of the motivations of Elisp hackers.



reply via email to

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