From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Improving GNU ELPA (was: Adding advisory notification for non-ELPA package.el downloads) Date: Tue, 11 Jul 2017 12:04:26 -0400 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1499789200 30037 195.159.176.226 (11 Jul 2017 16:06:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 11 Jul 2017 16:06:40 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 11 18:06:37 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dUxgI-0007Wt-Nc for ged-emacs-devel@m.gmane.org; Tue, 11 Jul 2017 18:06:34 +0200 Original-Received: from localhost ([::1]:47287 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dUxgO-0004cR-33 for ged-emacs-devel@m.gmane.org; Tue, 11 Jul 2017 12:06:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42215) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dUxeY-0003Bj-Te for emacs-devel@gnu.org; Tue, 11 Jul 2017 12:04:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dUxeU-0002J8-Lo for emacs-devel@gnu.org; Tue, 11 Jul 2017 12:04:46 -0400 Original-Received: from [195.159.176.226] (port=35931 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dUxeU-0002Ix-ER for emacs-devel@gnu.org; Tue, 11 Jul 2017 12:04:42 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1dUxeK-0001nF-Dz for emacs-devel@gnu.org; Tue, 11 Jul 2017 18:04:32 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 59 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:aSpCzdCHIgdhC42jG6Dl35SJopA= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:216485 Archived-At: > for inclusion. Getting into ELPA requires subtle git invocations that end > up mashing up the history of your project with that of tens of others, while > fearing to break the entire ELPA repo because of a missing copyright line > in a test file. > And ELPA makes maintaining the package more painful, too: picking out the > commits made by others and copying them on your personal repo requires > further arcane git invocations — same for importing new commits from your > personal repo. And of course you lose other MELPA goodies, like getting > download statistics. While most of the above only applies to the case where you put your package as a "subtree" rather than an "external", I can't say that the criticism is unfair. And I indeed think that if we want to expand the use of ELPA, the proverbial someone should first work on the elpa.gnu.org infrastructure. It's all a simple matter of writing scripts, really, so help is very welcome. I know of the following: - when someone commits to elpa.git we get an elpa-diffs email which I used to then forward to the corresponding package maintainer. This forwarding is currently broken because of changes to my email server. This should really be done in elpa.gnu.org instead of iro.umontreal.ca anyway, so I don't intend to fix the old setup. - elpa.gnu.org should be notified (e.g. via the elpa-diffs thingy) whenever a commit is made to an elpa package, and should then build the corresponding package (if the version was changed). Currently, we just rebuild the world blindly twice a day, which is both more costly and adds a ~6h delay. More importantly, this will make the handling of "externals" just as efficient as "subtrees", so it will scale a lot better. - once that's in place, we could also consider supporting "one repository per package" rather than "one branch per package". - we have the web-server log, so we could provide download stats. Publishing on GNU ELPA is inevitably more work than on MELPA: - you need to sign paperwork. - we don't want to fetch from non-GNU servers, so we need the maintainer to push to elpa.git explicitly. - we want the elpa.git code to be writable by "Emacs maintainers", so the package's maintainer will sometimes have to deal with commits made outside of his control. But we could tilt the balance the other way. The way I see GNU ELPA, it doesn't just provide package distribution but also package hosting, so we could maybe move towards a gitea/gogs/gitlab/younameit system for it. We could add some wiki or some way for users to vote up/down and add comments to each package, ... IOW, elpa.gnu.org needs some tender love from someone who understands the web. So far I've been doing most of the maintenance and I don't understand the web, really. Stefan