From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Re: Emacs release and bundling GNU Elpa Date: Mon, 22 Jun 2015 18:45:50 +0100 Message-ID: References: <83si9jhi5u.fsf@gnu.org> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1434995165 30288 80.91.229.3 (22 Jun 2015 17:46:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Jun 2015 17:46:05 +0000 (UTC) Cc: Stefan Monnier , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 22 19:46:05 2015 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 1Z75nH-0001W8-TW for ged-emacs-devel@m.gmane.org; Mon, 22 Jun 2015 19:46:04 +0200 Original-Received: from localhost ([::1]:41380 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z75nH-0008Ip-CJ for ged-emacs-devel@m.gmane.org; Mon, 22 Jun 2015 13:46:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55614) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z75n8-0008Ig-Ox for emacs-devel@gnu.org; Mon, 22 Jun 2015 13:45:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z75n7-000164-Fs for emacs-devel@gnu.org; Mon, 22 Jun 2015 13:45:54 -0400 Original-Received: from mail-lb0-x236.google.com ([2a00:1450:4010:c04::236]:34015) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z75n5-00015D-2m; Mon, 22 Jun 2015 13:45:51 -0400 Original-Received: by lbnk3 with SMTP id k3so7387589lbn.1; Mon, 22 Jun 2015 10:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=l8zpGnsgvBuFwadBfup/J36aBKBcPRO8mzxk3cwqt9M=; b=S+TuGB/sHz3TQVDvvqkygg2lXOsSEMHQ7Ku42IjDMD9uJmyelvVrXQd4drI3066BKf IlcL2fy1zHUAkUqwlElcPplGVw371vkZyKoQKVQExV9/ZpFofsFh0V9i3McEoVYAClL3 HstW2ezX0R3Y26+lCozlUyXBbdWHyPwyoM/XEaGxGUi+nDjEY3S+kv2mAWyexTUOudik 4qwIAsSfIXTyvcDAE6zkIb/t0vI2wqbVnJRnfazz5TjaCE1LFDz1doH5U8DeW16uaF4d yIYthwUv+58biCc86C0St4M7uBUkTO/DSzPi7LOdMsbfcqdE6eZsuCOasBkBKyBod+H4 hLVA== X-Received: by 10.112.25.69 with SMTP id a5mr30967937lbg.16.1434995150264; Mon, 22 Jun 2015 10:45:50 -0700 (PDT) Original-Received: by 10.25.214.133 with HTTP; Mon, 22 Jun 2015 10:45:50 -0700 (PDT) In-Reply-To: <83si9jhi5u.fsf@gnu.org> X-Google-Sender-Auth: dIFBX9L_3qqFnzS__xMkO93PgAg X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::236 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:187390 Archived-At: I was thinking that keep a list somewhere of packages that we want to pull from elpa. At build time, these will be copied from "./elpa.git/" (which will probably be a submodule containing the elpa repo) to "./lisp/from-elpa/" (which will be a .gitignored directory containing nothing initially). This should also involve copying info manuals from "./elpa.git/" to the right place. I see only two differences from the current situation: 1. Instead of the usual `git pull && make bootstrap` the user wil be expected to do something like `git pull && git submodule update && make bootstrap` which should be a no-brainer (maybe there's a hook or something that can automatically do the update when `pull'ing). 2. To push a change, instead of editing the file inside lisp/from-elpa/ you have to edit the file in the elpa.git submodule. This is a relevant difference, but it shouldn't lead to issues. Since the from-elpa dir is gitignored, there's no way for people to accidentally commit changes to it. And having to edit on elpa.git is certainly an improvement over having to edit on both emacs and elpa.git. 2015-06-22 16:33 GMT+01:00 Eli Zaretskii : > Fair disclosure: I don't like this "move to ELPA" attitude. I think > the net result will be more bugs because of unsynchronized development Why would it unsynchronise? Everyone who `git pulls` today at 12pm has the same Emacs. Similarly, under this alternative, everyone who pulls && updates today at 12pm will have the same Emacs. > and less exposure of packages to people who track development on > master, These packages will effectively be part of master. Pulling them in will be a part of the build process, why would there be less exposure? > and more hassle due to the need to work with more than one Git > repository, multiple development philosophies, etc. This is a fine point against moving out of emacs packages that are only in emacs. OTOH, we can start with these other two options (a) pull into emacs packages that are only on Elpa (like company), and (b) move out of emacs packages that are on both repositories (these are already a hassle, and the hassle would only be reduced). > At step 1, we'd have the following novelties: > > . Package developers will have to abide by some of the core's > development methodology, like freezing development when core does > so, perhaps using release branches, timely fixing of critical or > blocking bugs during pretests, etc., let alone abiding by style and > documentation guidelines. Yes. This wouldn't be applied to all of elpa.git, only to those packages that are bundled in. > . Core maintainers will probably start pushing more changes to the > packages, something I'm not sure package developers will like. > Alternatively, we will have to develop procedures and protocols we > don't currently have for having the package developers themselves > expedite fixing of certain problems deemed urgent. Yes, this is something the package developer would have to be aware, in order for a package to be bundled in. Nobody is forced to bundle a package in Emacs. OTOH, for packages that are currently on both repos this already happens, and it will be much better if for the developer if these changes are all made to the same place. > . We'd need to find a way of providing ChangeLogs for the packages, > either by merging their Git logs somehow, or by keeping their > ChangeLogs in separate directories (which would mean each package > will have its own directory, making load-path longer). Keep their ChangeLogs in the same place as their source (in the "./elpa.git/packages/package-name/" directory). This has nothing to do with the load-path. The load-path will point to "./lisp/from-elpa" (which is where we copy the sources before compiling). > . We'd need to produce NEWS entries for the packages, which will > probably mean the packages will have to maintain their own NEWS > files, using the same methodology and style as in core development. Yes. That can sit alongside the ChangeLog. > . If any of the packages have manuals, or are mentioned in the Emacs > manuals, changes there will have to be merged as well, and we will > have to track those updates, e.g. like we do in NEWS. As I said at the start. Just like the sources are pulled in at compiled time, so are their manuals. Changelog entries for edits to the manual go in the package's ChangeLog. > . Our defcustom's have a ':version' tag, which is useful for quickly > examining new options since some release -- how will this work in > packages whose release cycle is not synchronized with Emacs? They will use the :package-version tag. Like packages have always done.