From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?utf-8?B?7KGw7ISx67mI?= Newsgroups: gmane.emacs.devel Subject: Re: pull requests Date: Mon, 30 Mar 2020 17:25:26 +0900 Message-ID: <49236D54-08F9-4665-97A9-07A351DB0977@icloud.com> References: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="63256"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Dmitry Gutov , eliz@gnu.org, cpitclaudel@gmail.com, Emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Mar 30 10:26:10 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 1jIpkI-000GLf-QS for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Mar 2020 10:26:10 +0200 Original-Received: from localhost ([::1]:46352 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIpkH-0007cQ-Qp for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Mar 2020 04:26:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59836) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIpjk-00075o-9I for emacs-devel@gnu.org; Mon, 30 Mar 2020 04:25:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jIpji-0004DY-EO for emacs-devel@gnu.org; Mon, 30 Mar 2020 04:25:36 -0400 Original-Received: from pv50p00im-ztdg10021101.me.com ([17.58.6.44]:42320) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jIpji-0004Bw-4y for emacs-devel@gnu.org; Mon, 30 Mar 2020 04:25:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1585556732; bh=5d3CKzb0b6XTdAbk7NW641SWYDBGgwhOe1n8R3c2d40=; h=Content-Type:From:Subject:Date:Message-Id:To; b=vGcyIOAKs9fee3eVv1WJyKzvJw1XjLU6L4g2bmAC+5zjALTjfp7RW31F4XS/MHVHN pguSNa28OKqXkhpnPnwfbl5hntv/Qa5AUar14WbO3UOtQtxtXnA1rTXheZabTOTtGN PPdYmdk8InCriY5Yox9nqZUcVvgjKQcLUvfq4GQs1twfGAKJdX2HeYl44T+cPFfOJH Lv8hzxvITaypTxItLSk3z2y18fTmYHl1zUFJmGnwfc6vWUkn5g3zeKalQaVi4VCiy9 RaiQar1zpBBx3IDEYVosluJKepYwR2SBOV+uVaP2a80BOYlpx65ra6cswZ+TTeD8EW 8bzesXK8LTbUQ== Original-Received: from [10.66.144.64] (unknown [223.62.219.7]) by pv50p00im-ztdg10021101.me.com (Postfix) with ESMTPSA id 197991804C7; Mon, 30 Mar 2020 08:25:32 +0000 (UTC) In-Reply-To: X-Mailer: iPhone Mail (17E255) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-03-30_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-2003300080 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 17.58.6.44 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:245992 Archived-At: > 2020. 3. 30. =EC=98=A4=ED=9B=84 12:39, Richard Stallman =EC=9E= =91=EC=84=B1: >=20 > =EF=BB=BF[[[ 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. ]]] >=20 >>> That is a statement of intentions, not facts. Emacs developers >>> would know those intentions, but other Emacs users might have no >>> idea about them. >=20 >> That's why we have forges, with self-explanatory web interfaces and even=20= >> integrated help for new users. >=20 > 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. >=20 > This is the scenario I pointed at: >=20 > 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 th= e > point clear, B will not know it is non-installed. B will only see > that it is in the standard GNU Emacs repo. If GNU hosts a forge with PR support working similar to GitHub or GitLab, th= e URL won=E2=80=99t point to the standard GNU Emacs repo, it will point to a= custom fork (which IMHO nobody can really confuse).=20 For example, let=E2=80=99s say that a Git Forge with a PR model is running o= n nongnu.org (for instance). The canonical Emacs repo (running by an organiz= ation account named =E2=80=98gnu=E2=80=99) will be accessible from the URL n= ongnu.org/gnu/emacs.git. If one wants to make a change on Emacs, one can mak= e an account on nongnu.org (let=E2=80=99s say =E2=80=98pcr910303=E2=80=99), p= ress the Fork button from the gnu/emacs repo, and the fork will be accessibl= e from the URL nongnu.org/pcr910303/emacs.git. If I want to merge some code i= nto the canonical emacs repo (with using the web UI), I can push some commit= s to pcr910303/emacs, go to nongnu.org/gnu/emacs and make a PR across repos.= If one wants to check out the change, one can pull from =E2=80=98nongnu.org= /pcr910303/emacs.git=E2=80=99. The URL clearly indicates that it=E2=80=99s n= ot the official repo, hence it won=E2=80=99t be a problem. Also, currently non-installed patches can be downloaded from the GNU Emacs m= ailing list from the URL lists.gnu.org. If the user uses something like curl= to download the patch, one will not know whether it=E2=80=99s installed or n= ot. I think it won=E2=80=99t be that different. >> 99% of the users who would be looking at them, would be doing so through=20= >> the web interface of the force software. >=20 > In that scenario, large numbers of users might not go through that interfa= ce. > They might not even know there is a web interface. >=20 >> When you were talking about hiding PRs from non-developers, you meant=20 >> hiding in the web interface, right?=20 >=20 > 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. >=20 >> Because it would be hard to hide=20 >> them in the mailing lists, >=20 > 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. >=20 > 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. >=20 > I know that many other projects use pull requests and are happy with them.= > But those projects do not share our nontechnical overriding goals: >=20 > * Do not distribute nonfree software. > * Do not publish text that recommends nonfree software. > * For some projects, do not include code without legal papers. >=20 > 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.) >=20 > Keeping uninstalled code in the same repo as the installed code makes > it too easy to overlook the difference between them. >=20 >> But if we manage to support merge requests from contributors without=20 >> commit access, and do it without external repositories, we could just as=20= >> well mandate that all such branches have names prefixed with=20 >> "merge-request/", and that will avoid any confusion. >=20 > 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. >=20 > How, in practice, would we ensure that all installation proposals > have a name starting with 'merge-request/'? >=20 > How would we find out if many users begin accessing a branch whose > name begins with 'merge-request/'? >=20 > How would we find out if one is created with a name that doesn't > start with that prefix? >=20 > Could we arrange that those branches start out accessible only to > maintainers, then become generally accessible when a maintainer says > "Make this accessible"? >=20 >=20 >=20 > --=20 > 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)