From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs] Date: Sun, 17 May 2020 21:27:51 +0300 Message-ID: References: <35DBF02E-44D7-41E5-A217-7D6EC84ED221@icloud.com> <4e937898-ae46-710a-cbca-e452a1156fa1@yandex.ru> <405FCFAB-30E4-4F98-81DA-3B09933E86D0@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="43119"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: joostkremers@fastmail.fm, ams@gnu.org, phillip.lord@russet.org.uk, pcr910303@icloud.com, Emacs-devel@gnu.org To: Eli Zaretskii , rms@gnu.org, Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 17 20:28:29 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 1jaO1V-000B8H-Cc for ged-emacs-devel@m.gmane-mx.org; Sun, 17 May 2020 20:28:29 +0200 Original-Received: from localhost ([::1]:58948 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jaO1U-0004G1-FC for ged-emacs-devel@m.gmane-mx.org; Sun, 17 May 2020 14:28:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41144) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jaO10-0003ou-HH for Emacs-devel@gnu.org; Sun, 17 May 2020 14:27:58 -0400 Original-Received: from mail-wr1-x442.google.com ([2a00:1450:4864:20::442]:40998) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jaO0z-0004Iw-I1; Sun, 17 May 2020 14:27:58 -0400 Original-Received: by mail-wr1-x442.google.com with SMTP id h17so9199841wrc.8; Sun, 17 May 2020 11:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=C33qX2SVfCmzdAtloUBeqJTmiFY9u+OM198P6l6WmzY=; b=SQmP7ENNt6XbHsdA1E9N4s1kKi57+Hvh0CT4YyEd0CpdwMM+9b5+JmGqWsmvU23Roa epxXCiIXyefcXHQQb84Eyd95pSZaJR2E+kmITyzPYOKNY8w7mv7OYiK+4RZesD836wzD kdJsWCJaNRG+1RToawmJTkJSQMM0/ZEWxFfrZinDkXLMbF/Z6sQPxluRt3CU9M/HAzei h7US1W4IrDtVKbaMyDvLGeTr50EQKnMxJb9x8y1ANdC4rYKrePooEvC/YRPNC5Gdu5Er d0VdWDEn+a5Qw+SBOHx56GecoP4wFyx6L1JwsUu1o8cd+i4Zv7Kba1J2T0FasZ7cZnmr o81g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=C33qX2SVfCmzdAtloUBeqJTmiFY9u+OM198P6l6WmzY=; b=UWT2sjd4170/m5JJVJBowqbhmroMC6Mf87PpD//lzRN/UdFh6BItWygVvWnOgkxuna TiEkcnv2iNOaNE31r3n4FK1QcsPTDvQa1pphlBVdkzqamzDNfpSqQeBgMie98P3f6gsM 3I5vJGEZwH+dlk8/pPfr8x6fljsG5aM98/qQMsQvEMJnmoLVdjKZD/r4wQUxejIkv5Yk bUoKD/g7rkxZd8W+4Tmjik8Kpz9ZTAmXqPWIYsOt6GIqPx9yC9Jm6CR2MoCBh1Ke1w9V dSWNAwif7Ntl+zCKi39JTDLO7VMa4MYVHBCRTKtlM79yuD7KWk/H4Qy3NvAXd7i5CmgL csqg== X-Gm-Message-State: AOAM532XZwuW8P6GhND2foKcNv2V1Rv928POXOVryhrpjI31VRl2BeKh nONHK8XuHruFOAdOfuNSmak= X-Google-Smtp-Source: ABdhPJy10XZZKq9vVezXKgwT1zhbjM3kbl7+f5rcNoYqJ+UyzvAB/1m+lBTOe74uCgw7pvkN1B8u1Q== X-Received: by 2002:adf:a4d5:: with SMTP id h21mr16025742wrb.288.1589740074666; Sun, 17 May 2020 11:27:54 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id q144sm13743123wme.0.2020.05.17.11.27.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 17 May 2020 11:27:53 -0700 (PDT) In-Reply-To: <405FCFAB-30E4-4F98-81DA-3B09933E86D0@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::442; envelope-from=raaahh@gmail.com; helo=mail-wr1-x442.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action 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:250637 Archived-At: On 17.05.2020 17:24, Eli Zaretskii wrote: > I'm saying that maybe we shouldn't agree so easily to put a package on ELPA if the author would like more than just distribution services. I'd say it all depends. We probably aren't going to simply follow what the author will be asking for, either. Do they want code review? We could do it once (couldn't we?), but if the author wants all the changes reviewed all the time, we would probably do that only for most important packages. Ones that will be enabled for default, maybe? On the other hand, I don't see why we couldn't do code reviews on ELPA for select packages, if the authors ask for it. I don't see that happening a lot anyway. Do they simply ask to be included? Perhaps we should ask why. Up until now, we often pointed at GNU ELPA and proposed that the package will live there. It seems to have worked out fine in those cases. Even aside organizational issues (different upstreams, etc), simply including a package in Emacs will hardly help it gain users (people don't often examine the contents of our distribution). Whereas being featured in 'M-x list-packages' with a good summary *can* make it well-known. Do they want to be included and turned on by default? This seems like a good reason, if we really like it. On the flip side, not every discussion that starts with 'I propose to put pkg-X in GNU ELPA' should end there. As I wrote in another thread, maple-minibuffer is something we should consider sooner or later for the default behavior, for friendlier positioning of the minibuffer on graphical displays. Another example is elegant-emacs, suggested in yet another thread by Nicolas P. Rougier. There's nothing stopping us from featuring it in GNU ELPA (right?), but we would get the most value if we really examine it and look for pieces to put into the vanilla Emacs by default.