From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: Why are so many great packages not trying to get included in GNU Emacs? Date: Fri, 24 Apr 2020 20:55:54 -0700 Message-ID: <87imho8bhx.fsf@ericabrahamsen.net> References: <9mmFgzvrBwjt_n_VJyaJdXINraNi5HsGpwq-0MLeKiJA7kG2BQA4uywrzjyz7lpRS0OZDpjEi8lspOKYUA7P_QsODsDew_8nbH960G55fmY=@protonmail.com> <97DA7804-F647-4A1D-B8E0-AFFE7A324C64@gmail.com> <87d07xamrg.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="66657"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: casouri@gmail.com, ndame@protonmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 25 05:56: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 1jSBvZ-000HEV-3y for ged-emacs-devel@m.gmane-mx.org; Sat, 25 Apr 2020 05:56:29 +0200 Original-Received: from localhost ([::1]:58014 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSBvY-0003u1-47 for ged-emacs-devel@m.gmane-mx.org; Fri, 24 Apr 2020 23:56:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42854) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jSBv5-0003M5-US for emacs-devel@gnu.org; Fri, 24 Apr 2020 23:56:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jSBv5-0001Ww-9M for emacs-devel@gnu.org; Fri, 24 Apr 2020 23:55:59 -0400 Original-Received: from ericabrahamsen.net ([52.70.2.18]:58816 helo=mail.ericabrahamsen.net) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jSBv4-0001Wa-TC; Fri, 24 Apr 2020 23:55:58 -0400 Original-Received: from localhost (c-73-254-86-141.hsd1.wa.comcast.net [73.254.86.141]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 7E7DBFA02A; Sat, 25 Apr 2020 03:55:55 +0000 (UTC) In-Reply-To: (Richard Stallman's message of "Fri, 24 Apr 2020 23:31:37 -0400") Received-SPF: pass client-ip=52.70.2.18; envelope-from=eric@ericabrahamsen.net; helo=mail.ericabrahamsen.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/04/24 23:55:56 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Received-From: 52.70.2.18 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:247748 Archived-At: Richard Stallman writes: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > I think it could be even simpler than that: ELPA is built every 24 hours > > right now. If we just registered external repos with ELPA, part of the > > build process could be pulling from those repos automatically > > That is rather breathless, so I can't concretely understand the > proposal. I can't start to think about what specific consequences it > might have. I am not sure which situations you propose to use this > solution for. > > If this is meant as a way to implement pull requests, there is no need > for it. We will not implement pull requests by copying proposed > patches into our repo before they are installed. > > There are various ways to implement pull requests. The way I hope we > will do it is that maintainers can ask to see the contents of the > request, and commit it to our repo if/when that is proper. Until that > time, the patch won't be in our repo at all. > > Or maybe you're proposing a way to make a given package in GNU ELPA > virtually included from some other GNU-managed repository; the method > consisting of copying each commit automatically from that other repo > to the GNU ELPA repo. Yes, it's this latter I was referring to -- I don't have much feeling about pull requests either way. > It is ok to do that, assuming the other repo is managed appropriately, > and your method could do it. Other methods could give equivalent > results. We could use whichever method is most convenient. > > The crucial thing is that the repo where the package is really maintained > be managed carefully in regard to who can commit changes. And this was ultimately Stefan's concern, and the reason why my suggestion is probably no-go. But no matter!