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: pull requests Date: Mon, 30 Mar 2020 20:49:20 +0300 Message-ID: <2ddb14d9-2a1f-ccfb-b5ea-ae9fc41c3bd1@yandex.ru> 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> 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="124631"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 Cc: 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 19:50:36 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 1jIyYW-000WJq-D6 for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Mar 2020 19:50:36 +0200 Original-Received: from localhost ([::1]:54288 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIyYV-0006B7-AY for ged-emacs-devel@m.gmane-mx.org; Mon, 30 Mar 2020 13:50:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38323) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jIyXO-0004IH-8R for emacs-devel@gnu.org; Mon, 30 Mar 2020 13:49:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jIyXM-0002Yl-SO for emacs-devel@gnu.org; Mon, 30 Mar 2020 13:49:26 -0400 Original-Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:52426) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jIyXM-0002Yb-HR; Mon, 30 Mar 2020 13:49:24 -0400 Original-Received: by mail-wm1-x32c.google.com with SMTP id z18so20921281wmk.2; Mon, 30 Mar 2020 10:49:24 -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=0EUd62ApP8iWDtFXQT3WRrmdz5UgAPf0DDISKupOR3Y=; b=u/KSe1+0t7MGIULLXNn2H19v1TRJ9fkvNgTdvG4GviO1bV3+JMNDwPgYE2NIqZX6IO Xj4xd8pDq+zUaQls7A5V+goxW1SUsdxJ/rVlKMG2HwFFScByzvimSFCkern/xEtLIz9d AEIJPnmJqF6pX1U69vQaIF+FoXXugzn93p+AjlaM5RJKaLWnUl7q0TfmHF6ElXcsK5xi jBFnOODL7KJEGlDegeOlA4CZr0RGvcLXehSVBHtqg9C1fjSlJqrA0qY1iQPheYIwIdQI 4uje1GGUXD8SEpCaxL913DklwMUQOf7kUQMt9jakPewDBxD7n6g8rzMwcTiq9IQ9eeMQ Kn6g== 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=0EUd62ApP8iWDtFXQT3WRrmdz5UgAPf0DDISKupOR3Y=; b=XlLf9qUy7ZyEGtRHqV9OY1z17ZNbXD4OUGqqDgW0CQtL45alg3QnnYy/lgoqHm7UDy CW1uIs6Ung19ZmxnWToPrw6UJ+HBGtSu8RAawuafrNZxOON2XQRIcgwqUklZ4vytfBBM hyBEjdwswBhqJHnacp8uAqCzMO5cUnBzCwACBhvOc5WVH5Edlesv3Rvlqp5QI4szrLrZ 0JeWHOx+FwQySJ3uYmGyhEaTe4sb8bv6McDyZyJaBno+iJOPi+ZBUfkoQxLJOtJu/4bC Iclb9s5hOYM46OqKAEhLNxpY9DHyqBUNVo5zQWzEnXZRyWssJ10sKxUX8iB3ZbAPo+EX zrfA== X-Gm-Message-State: ANhLgQ0Z9ud5o5ZPNwRJY7m0skM3dDzbGGpKiBZTHBPuC5c6hXEktdIh IqGUchsiCokWU5OynO9QdMgiV07H X-Google-Smtp-Source: ADFU+vut7oZDkyYIrIOZPmuznHU7/tEABPLabicuQPAgLleq0AjXNrIdn+tufDpidh92JQVT6VcNog== X-Received: by 2002:a05:600c:2317:: with SMTP id 23mr405313wmo.85.1585590562718; Mon, 30 Mar 2020 10:49:22 -0700 (PDT) Original-Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id d7sm8635397wrr.77.2020.03.30.10.49.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 Mar 2020 10:49:21 -0700 (PDT) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::32c 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:246044 Archived-At: On 30.03.2020 06:38, Richard Stallman wrote: > 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. It's hard to optimize for people willing to misunderstand things. At some point we have to just draw the line. > > 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. I mean... if it's not too hard to implement, that would be okay with me, as long as the web UI shows the PRs even to unauthenticated users. The latter is not a hard necessity, of course, but I believe that more transparency in Emacs's development process, the ongoing discussions, etc, via the "forge" interface would benefit it a lot. Users will comment more, follow the development of new features more, and will thus be encouraged to submit more patches themselves. > 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. To be clear, we already have branches in the repo which 200+ people can push to. If we're not worried about them, are we worried only about branches created by "unauthenticated" users? Being able to facilitate that is a challenge in itself (+). > Keeping uninstalled code in the same repo as the installed code makes > it too easy to overlook the difference between them. One way to solve that would be to use a forge software that makes it easy to have multiple repositories (one per user, even), with fast "forking" action. Gitlab is not there, alas. > > 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/'? If we manage to solve the problem (+) above, we can include that as a part of the solution. Maybe the unauthenticated users would send patchsets over email, and whatever code will be set up to handle that, could enforce whatever branch naming scheme that we choose. > How would we find out if many users begin accessing a branch whose > name begins with 'merge-request/'? Savannah admins might help with that. Some HTTPS proxy, maybe. > How would we find out if one is created with a name that doesn't > start with that prefix? Is that question different from the previous-previous one? > Could we arrange that those branches start out accessible only to > maintainers, then become generally accessible when a maintainer says > "Make this accessible"? You seem to be trying to combine the two requirements together now, to make an even more difficult requirement. But to answer that question: the forge software, or the Git server software, or a combination of them, have to support that.