From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: pull requests Date: Sun, 29 Mar 2020 23:38:26 -0400 Message-ID: References: <87mu87ji39.fsf@dick> <87v9mvp2ms.fsf@blind.guru> <87d093f6lj.fsf@dick> <87369yc79r.fsf@dick> <83mu828c7d.fsf@gnu.org> <7b0e82fd-8928-26d2-4bed-331593685f36@gmail.com> <83h7ya7wne.fsf@gnu.org> <8b7d5a28-8193-cd12-bb47-b70c7eee6db5@gmail.com> <83eetd962o.fsf@gnu.org> <281f88c3-ea09-3486-5532-5084881bf38b@yandex.ru> <4ceaa8ac-9a19-d874-51d6-8056bcb46b2c@yandex.ru> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="66837"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eliz@gnu.org, cpitclaudel@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Mar 30 05:39:15 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 1jIlGc-000HGu-VC for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Mar 2020 05:39:14 +0200 Original-Received: from localhost ([::1]:44286 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIlGc-0000xI-0f for ged-emacs-devel@m.gmane-mx.org; Sun, 29 Mar 2020 23:39:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33752) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIlG0-0000JY-IC for emacs-devel@gnu.org; Sun, 29 Mar 2020 23:38:38 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36768) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jIlFx-0007Od-L1; Sun, 29 Mar 2020 23:38:34 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1jIlFq-00023I-VV; Sun, 29 Mar 2020 23:38:27 -0400 In-Reply-To: <4ceaa8ac-9a19-d874-51d6-8056bcb46b2c@yandex.ru> (message from Dmitry Gutov on Sat, 28 Mar 2020 19:14:11 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:245984 Archived-At: [[[ 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. ]]] > > That is a statement of intentions, not facts. Emacs developers > > would know those intentions, but other Emacs users might have no > > idea about them. > That's why we have forges, with self-explanatory web interfaces and even > integrated help for new users. That would inform some users, those who do certain things. But in the scenario I pointed at, the users would not do those things, so they would not get the information. This is the scenario I pointed at: Suppose A sends B a URL pointing to a branch with non-installed patches. If A doesn't warn B, or if A is too terse and does not make the point clear, B will not know it is non-installed. B will only see that it is in the standard GNU Emacs repo. > 99% of the users who would be looking at them, would be doing so through > the web interface of the force software. In that scenario, large numbers of users might not go through that interface. They might not even know there is a web interface. > When you were talking about hiding PRs from non-developers, you meant > hiding in the web interface, right? I mean blocking access to them _in the repo_, for all interfaces. If you're not logged in as a member of the project, you would not be allowed to check out that branch by running git. Because it would be hard to hide > them in the mailing lists, The mailing list is a different kind issue. If you abstract away the practical differences, you might think it is the same; but those practicalities change everything, in this case. I am not talking about adding security where we have done ok without it. My aim is to limit the possible new danger from the change that you are asking for. I know that many other projects use pull requests and are happy with them. But those projects do not share our nontechnical overriding goals: * Do not distribute nonfree software. * Do not publish text that recommends nonfree software. * For some projects, do not include code without legal papers. We have a system for avoiding this: the package maintainers decide what to install, and they check these criteria before installing anything. (See the GNU Coding Standards and GNU Maintainer's Guide.) Keeping uninstalled code in the same repo as the installed code makes it too easy to overlook the difference between them. > But if we manage to support merge requests from contributors without > commit access, and do it without external repositories, we could just as > well mandate that all such branches have names prefixed with > "merge-request/", and that will avoid any confusion. I am not convinced it would work "just as well." But that idea is worth thinking about. we need to think _not only_ about how we would intend this facility to be used, but also how to make sure it is not misused. How, in practice, would we ensure that all installation proposals have a name starting with 'merge-request/'? How would we find out if many users begin accessing a branch whose name begins with 'merge-request/'? How would we find out if one is created with a name that doesn't start with that prefix? Could we arrange that those branches start out accessible only to maintainers, then become generally accessible when a maintainer says "Make this accessible"? -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)