From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs] Date: Wed, 13 May 2020 19:20:41 +0300 Message-ID: <831rnn7qna.fsf@gnu.org> References: <35DBF02E-44D7-41E5-A217-7D6EC84ED221@icloud.com> <83d07984ux.fsf@gnu.org> <83tv0l6kgd.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="100297"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, joostkremers@fastmail.fm, Emacs-devel@gnu.org, ams@gnu.org, pcr910303@icloud.com, phillip.lord@russet.org.uk To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 13 18:22:28 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jYu9M-000Pzb-Rz for ged-emacs-devel@m.gmane-mx.org; Wed, 13 May 2020 18:22:28 +0200 Original-Received: from localhost ([::1]:43614 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYu9L-00067O-UM for ged-emacs-devel@m.gmane-mx.org; Wed, 13 May 2020 12:22:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46212) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jYu87-0004op-0h for Emacs-devel@gnu.org; Wed, 13 May 2020 12:21:11 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40767) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYu86-0007dT-EL; Wed, 13 May 2020 12:21:10 -0400 Original-Received: from [176.228.60.248] (port=1381 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jYu7w-0004kM-El; Wed, 13 May 2020 12:21:00 -0400 In-Reply-To: (message from Stefan Monnier on Tue, 12 May 2020 15:50:52 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:250148 Archived-At: > From: Stefan Monnier > Cc: rms@gnu.org, joostkremers@fastmail.fm, ams@gnu.org, > phillip.lord@russet.org.uk, pcr910303@icloud.com, Emacs-devel@gnu.org > Date: Tue, 12 May 2020 15:50:52 -0400 > > > Do we have a mechanism to declare that a package is not intended to be > > brought into core, unless changed to follow the same standards and > > guidelines as the core does? > > Being a GNU ELPA package does not mean "intends to be brought into core". > Never has, never will. Others seem to think otherwise. So maybe we should begin even farther back: by defining what it means to be a GNU ELPA package that is considered "compatible with core". Here's my definition: it is a package which we can move in or out of core whenever we like, and/or distribute it as part of an Emacs release, whether the Emacs source tarball or any auxiliary tarballs that are considered part of an official Emacs distribution. > > A package that is thus declared can then be exempt from some of the > > requirements (we still need to agree on which ones, though). > > If we only label those rare ones for which we do have plans to integrate > them, we don't need to "agree first" since in case of disagreement the > package just won't be integrated. I think we do need to agree up front. The reason is simple: a package that will never be "core-compatible" is of no special interest to us. When accepting it, we should only verify several simple technicalities. We don't need to pay any attention to later changes, we don't need to check its sources for use of any deprecated APIs, we don't need to be bothered by its documentation and by its being consistent with the rest of our conventions -- because our code will never directly call any of that package's APIs. In effect, we are just hosting the package in ELPA so that we could freely recommend it to our users and to other 3rd-party packages, and make package.el install it without any non-default configuration. That is not so for packages that we would decide to keep "compatible". > Personally I don't see much benefit in such labeling: the way I expect > it to work is rather: > - Shouldn't we include SuperFoo into the tarball? > - Oh, yes, good idea. Let's see ... is it in a good enough shape? > - Almost, we just have to fix this and that. > - OK, let's do that. > - [time passes] > - Alright, now this and that has been fixed, let's include it. > - Great, thanks, done. > No labeling involved. This is not a good idea, IMO. It would mean that deciding to include a package in a tarball or even optionally call from our sources would mean we need at that time to do all the review work we didn't before, which is a much larger job. More so if we are doing this with several packages at once, due to their dependencies. It is much easier to do this piecemeal over many moons. We would also need to ask the package developers to make all those adjustments at once, and they could rightfully ask us why we suddenly come up with all those requests when the package already happily lives several years on ELPA in its present form. It would be hard to come up with a good answer to that. So no, your proposal doesn't really work for me, sorry.