all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Bastien <bzg@gnu.org>
To: emacs-devel@gnu.org
Subject: Re: async 1.0
Date: Sun, 24 Jun 2012 17:42:44 +0200	[thread overview]
Message-ID: <87pq8od8cr.fsf@gnu.org> (raw)
In-Reply-To: <87r4t4zr9l@ch.ristopher.com> (Christopher Schmidt's message of "Sun, 24 Jun 2012 16:02:59 +0100 (BST)")

Hi Christopher,

Christopher Schmidt <christopher@ch.ristopher.com> 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.

Best,

-- 
 Bastien



  reply	other threads:[~2012-06-24 15:42 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <m2hau86tfk.fsf@vulcan.local.i-did-not-set--mail-host-address--so-tickle-me>
     [not found] ` <E1ShM8F-0006IY-L9@fencepost.gnu.org>
     [not found]   ` <m2txy51z1k.fsf@newartisans.com>
     [not found]     ` <E1ShiKM-0000Aa-5G@fencepost.gnu.org>
2012-06-21 21:23       ` async 1.0 John Wiegley
2012-06-22  7:00         ` Teemu Likonen
2012-06-22 10:54           ` John Wiegley
2012-06-22 12:39             ` Michael Albinus
2012-06-22 22:02               ` John Wiegley
2012-07-04 17:10                 ` Samuel Bronson
2012-07-05  4:09                   ` John Wiegley
2012-07-05 19:58                     ` Samuel Bronson
     [not found]             ` <82d34r8ej9.fsf@gmail.com>
2012-06-22 21:50               ` John Wiegley
2012-06-23  1:44                 ` Stefan Monnier
2012-06-23  3:00                 ` Stefan Monnier
2012-06-23 16:26                   ` Lennart Borgman
2012-06-23 21:08                   ` John Wiegley
2012-06-23 21:28                     ` Jeremiah Dodds
2012-06-23 21:50                     ` Thierry Volpiatto
2012-06-24 15:02                     ` Christopher Schmidt
2012-06-24 15:42                       ` Bastien [this message]
2012-06-24 21:01                       ` John Wiegley
2012-06-25 14:53                         ` Christopher Schmidt
2012-06-25 23:54                           ` John Wiegley
2012-06-24 21:12                       ` ELPA and core services John Wiegley
2012-06-24 21:40                         ` Lennart Borgman
2012-06-25  2:20                         ` Stefan Monnier
2012-06-25  4:39                         ` Stephen J. Turnbull
2012-06-25  6:01                         ` Achim Gratz
2012-07-03 14:38                           ` Tom Tromey
2013-01-22 19:13                             ` Achim Gratz
2012-06-25  4:32                       ` stdlib for Emacs? [was: async 1.0] Stephen J. Turnbull
2012-06-23  6:25                 ` async 1.0 Stephen J. Turnbull
2012-06-23 21:05                   ` John Wiegley
2012-07-01  8:16                   ` Michael Sperber
2012-06-22 11:38         ` Richard Stallman
2012-06-22 21:39           ` John Wiegley
2012-06-22 23:02             ` Richard Stallman
2012-06-23  7:46               ` zwz
2012-06-23 20:49                 ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pq8od8cr.fsf@gnu.org \
    --to=bzg@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.