From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Emacs release and bundling GNU Elpa Date: Mon, 22 Jun 2015 13:16:39 -0400 Message-ID: References: <83si9jhi5u.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1434993478 1814 80.91.229.3 (22 Jun 2015 17:17:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Jun 2015 17:17:58 +0000 (UTC) Cc: bruce.connor.am@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 22 19:17:47 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 1Z75Lt-0004mM-AB for ged-emacs-devel@m.gmane.org; Mon, 22 Jun 2015 19:17:45 +0200 Original-Received: from localhost ([::1]:41288 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z75Ls-0006Gj-OZ for ged-emacs-devel@m.gmane.org; Mon, 22 Jun 2015 13:17:44 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47597) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z75Lc-0006Ge-Oj for emacs-devel@gnu.org; Mon, 22 Jun 2015 13:17:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z75Lb-0002b2-L6 for emacs-devel@gnu.org; Mon, 22 Jun 2015 13:17:28 -0400 Original-Received: from mercure.iro.umontreal.ca ([132.204.24.67]:36729) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z75LV-0002ZB-Va; Mon, 22 Jun 2015 13:17:22 -0400 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 8625A9C173; Mon, 22 Jun 2015 13:17:21 -0400 (EDT) Original-Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id BCC671E5B8D; Mon, 22 Jun 2015 13:16:57 -0400 (EDT) Original-Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id F13C4B4086; Mon, 22 Jun 2015 13:16:39 -0400 (EDT) In-Reply-To: <83si9jhi5u.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 22 Jun 2015 18:33:33 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 132.204.24.67 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:187389 Archived-At: > . 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. Yup, no worse than what happens for current bundled packages. I'm not expecting major issues in this respect. Furthermore, the pressure to have the latest&greatest version bundled is less severe since users can easily install a newer version later on. > . Core maintainers will probably start pushing more changes to the > packages, something I'm not sure package developers will like. That's part of deciding which packages get bundled. Again, that's no worse than what happens with current bundled packages. > . 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). When installed via package.el, they currently each get their own directory indeed. Maybe we could combine some of those directories, but this decision will probably not be based on minor issues such as where to put the ChangeLog entries. > . 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. I was thinking of putting the NEWS entries of those packages in the normal NEWS file. They'd be updated by hand when we change the version of this elpa.git package that the emacs.git tree refers to (remember emacs.git wouldn't just say "bundle company", but "bundle version of company"). > . 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. package.el already knows how to handle manuals, and while we may decide to handle it slightly differently, I don't foresee any major issues there (at least none that are really important to solve). > . 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? Good question. This one has existed for a long time and is not directly related to whether ELPA packages get included in Emacs's tarball. > At the very least, some changes to support that in > customize-changed-options will be needed. > Similarly with make-obsolete: we will need at least some > standardized wording for the WHEN argument, to avoid confusion > between versions of Emacs and the packages. No. We can keep living with these problems unsolved. Of course, I'd be happy to see them solved, but bundling ELPA packages doesn't make them significantly more pressing. Stefan