From: Nic Ferrier <nferrier@ferrier.me.uk>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: package and testing rant (was Re: package.el, auto-installation, and auto-removal)
Date: Tue, 11 Nov 2014 11:41:16 +0000 [thread overview]
Message-ID: <87389qklr7.fsf@ferrier.me.uk> (raw)
In-Reply-To: <jwvlhniejsn.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Mon, 10 Nov 2014 18:24:21 -0500")
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> IIUC by "ELPA" above I guess you mean GNU ELPA (since "ELPA and MELPA"
> would otherwise combine with "and" two things of different nature).
>
>> The multi-packages users load in their emacs are tars. But the packages
>> that are checked in to ELPA are directories of files.
> ^^^^^^^^^^^^^^^^^^
> So I think here you mean elpa.git (part of the greater GNU ELPA).
Excellent clarification. That's what I mean in this instance.
> Indeed. Note that for all packages (even single-file packages) there
> are yet more build steps elsewhere:
> - the creation of the <foo>-autoloads.el.
> - the creation of the *.elc files.
No. Those are not build steps. Those are installation steps. The
package artifacts (the things delivered to end users) do NOT have
auto-loads files or elc files in them. If they do they shouldn't because
that's what Emacs package.el does when it installs them.
It should go:
build -> release -> install
elpa.git and MELPA are promoting:
release -> (build) -> install
I don't think it's bad that MELPA promotes that. That's their
business. But I do think it matters that elpa.git works that way.
> Note that there is a fair bit a pressure to *add* rather than remove
> magic steps (the first candidate in the list is to build the *.info
> files from the *.texi files).
I agree. If the build was clearly separated this pressure would move
away into the build tools.
>> And I am really starting to think we need better testing. 24.4 looked
>> like a slog to release and it still has many bugs.
>
> FWIW, I haven't heard of any case where the issues you're pointing out
> have resulted in actual problems. The only real reliability problem
> I've heard about linked to ELPA packages is the issue of
> compiling/installing a package when an older version is
> already installed.
Ok... I'm not sure I've come across an elpa.git package that has bugs
because it wasn't tested. But then I don't use many right now.
But my point is we agree (don't we?) that moving stuff into elpa.git
from core is broadly right and I want to encourage a testing culture.
Why do we want to move things into elpa.git? because we can fix bugs and
add features quicker.
Nic
next prev parent reply other threads:[~2014-11-11 11:41 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-07 13:45 package.el, auto-installation, and auto-removal Stefan Monnier
2014-11-07 14:12 ` Ted Zlatanov
2014-11-07 19:50 ` joakim
2014-11-08 4:27 ` Stefan Monnier
2014-11-10 14:55 ` Phillip Lord
2014-11-10 17:46 ` Ted Zlatanov
2014-11-10 20:27 ` Nic Ferrier
2014-11-10 21:49 ` Stefan Monnier
2014-11-10 22:02 ` package and testing rant (was Re: package.el, auto-installation, and auto-removal) Nic Ferrier
2014-11-10 23:24 ` Stefan Monnier
2014-11-11 2:53 ` Drew Adams
2014-11-11 11:41 ` Nic Ferrier [this message]
2014-11-11 16:03 ` Eli Zaretskii
2014-11-11 17:17 ` Nic Ferrier
2014-11-11 17:20 ` Stefan Monnier
2014-11-11 17:53 ` Eli Zaretskii
2014-11-11 16:24 ` Stefan Monnier
2014-11-11 17:15 ` Nic Ferrier
2014-11-11 15:57 ` Eli Zaretskii
2014-11-11 17:18 ` Stefan Monnier
2014-11-11 17:52 ` Eli Zaretskii
2014-11-11 18:04 ` David Kastrup
2014-11-12 3:20 ` Stephen J. Turnbull
2014-11-12 6:48 ` David Kastrup
2014-11-11 17:27 ` Nic Ferrier
2014-11-11 18:20 ` Achim Gratz
2014-11-12 16:13 ` Stefan Monnier
2014-11-12 17:00 ` Stephen Leake
2014-11-12 17:51 ` Nic Ferrier
2014-11-12 20:34 ` Stefan Monnier
2014-11-12 21:39 ` Nic Ferrier
2014-11-12 22:40 ` Stefan Monnier
2014-11-12 23:01 ` Nic Ferrier
2014-11-12 23:31 ` Stefan Monnier
2014-11-13 1:09 ` Stephen J. Turnbull
2014-11-13 5:06 ` Richard Stallman
2014-11-13 14:59 ` Nic Ferrier
2014-11-15 17:09 ` Stephen Leake
2014-11-15 18:20 ` Nic Ferrier
2014-11-16 3:49 ` Stefan Monnier
2014-11-13 8:18 ` Thien-Thi Nguyen
2014-11-13 10:53 ` Phillip Lord
2014-11-13 14:54 ` Nic Ferrier
2014-11-14 11:04 ` Phillip Lord
2014-11-14 22:56 ` Nic Ferrier
2014-11-12 18:15 ` Achim Gratz
2014-11-12 22:21 ` Stefan Monnier
2014-11-13 20:21 ` Achim Gratz
2014-11-12 13:05 ` Stephen Leake
2014-11-11 13:30 ` Phillip Lord
2014-11-11 14:12 ` Nic Ferrier
2014-11-11 16:26 ` Stefan Monnier
2014-11-11 17:13 ` Nic Ferrier
2014-11-12 16:14 ` Stefan Monnier
2014-11-12 17:02 ` Stephen Leake
2014-11-12 17:21 ` Stefan Monnier
2014-11-10 21:37 ` package.el, auto-installation, and auto-removal Stefan Monnier
2014-11-11 1:29 ` Ted Zlatanov
2014-11-11 2:26 ` Stefan Monnier
2014-11-11 2:59 ` Ted Zlatanov
2014-11-11 3:55 ` Stefan Monnier
2014-11-11 12:44 ` Phillip Lord
2014-11-11 13:31 ` Nic Ferrier
2014-11-11 11:31 ` Nic Ferrier
2014-11-11 16:22 ` Stefan Monnier
2014-11-11 17:10 ` Nic Ferrier
2014-11-11 19:36 ` Achim Gratz
2014-11-11 20:40 ` Nic Ferrier
2014-11-11 21:53 ` Stefan Monnier
2014-11-12 22:17 ` Nic Ferrier
2014-11-12 22:59 ` Stefan Monnier
2014-11-12 23:26 ` Nic Ferrier
2014-11-13 0:21 ` Stefan Monnier
2014-11-07 20:00 ` Nic Ferrier
2014-11-08 4:29 ` Stefan Monnier
2014-11-08 23:18 ` Nic Ferrier
2014-11-09 3:17 ` Stefan Monnier
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=87389qklr7.fsf@ferrier.me.uk \
--to=nferrier@ferrier.me.uk \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/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.