From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nic Ferrier Newsgroups: gmane.emacs.devel Subject: Re: package and testing rant (was Re: package.el, auto-installation, and auto-removal) Date: Tue, 11 Nov 2014 11:41:16 +0000 Message-ID: <87389qklr7.fsf@ferrier.me.uk> References: <87a943umku.fsf@lifelogs.com> <87ppcvm7fj.fsf@newcastle.ac.uk> <87vbmndk46.fsf@lifelogs.com> <87wq72ls2h.fsf@ferrier.me.uk> <87k332lnn3.fsf_-_@ferrier.me.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1415706101 17421 80.91.229.3 (11 Nov 2014 11:41:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Nov 2014 11:41:41 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 11 12:41:34 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xo9pF-0007nb-LZ for ged-emacs-devel@m.gmane.org; Tue, 11 Nov 2014 12:41:33 +0100 Original-Received: from localhost ([::1]:47983 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xo9pF-00005Z-7v for ged-emacs-devel@m.gmane.org; Tue, 11 Nov 2014 06:41:33 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46549) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xo9p7-00005T-Dr for emacs-devel@gnu.org; Tue, 11 Nov 2014 06:41:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xo9p1-0001Zm-HW for emacs-devel@gnu.org; Tue, 11 Nov 2014 06:41:25 -0500 Original-Received: from static.17.66.46.78.clients.your-server.de ([78.46.66.17]:55366 helo=po1.ferrier.me.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xo9p1-0001Zg-BV for emacs-devel@gnu.org; Tue, 11 Nov 2014 06:41:19 -0500 Original-Received: from nicferrier-dell-xps (140.35.155.90.in-addr.arpa [90.155.35.140]) by po1.ferrier.me.uk (Postfix) with ESMTPA id 81B73AC0498; Tue, 11 Nov 2014 12:59:39 +0100 (CET) Original-Received: from nicferrier-XPS13-9333 (localhost [127.0.0.1]) by nicferrier-dell-xps (Postfix) with ESMTPS id 1EA996BA00; Tue, 11 Nov 2014 11:41:17 +0000 (GMT) In-Reply-To: (Stefan Monnier's message of "Mon, 10 Nov 2014 18:24:21 -0500") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 78.46.66.17 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:176744 Archived-At: Stefan Monnier 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 -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