Re: pull requests

[조성빈 <pcr910303@icloud.com>]

> 2020. 3. 30. 오후 12:39, Richard Stallman <rms@gnu.org> 작성:
> 
> [[[ 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.

If GNU hosts a forge with PR support working similar to GitHub or GitLab, the URL won’t point to the standard GNU Emacs repo, it will point to a custom fork (which IMHO nobody can really confuse). 

For example, let’s say that a Git Forge with a PR model is running on nongnu.org (for instance). The canonical Emacs repo (running by an organization account named ‘gnu’) will be accessible from the URL nongnu.org/gnu/emacs.git. If one wants to make a change on Emacs, one can make an account on nongnu.org (let’s say ‘pcr910303’), press the Fork button from the gnu/emacs repo, and the fork will be accessible from the URL nongnu.org/pcr910303/emacs.git. If I want to merge some code into the canonical emacs repo (with using the web UI), I can push some commits 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 ‘nongnu.org/pcr910303/emacs.git’. The URL clearly indicates that it’s not the official repo, hence it won’t be a problem.

Also, currently non-installed patches can be downloaded from the GNU Emacs mailing list from the URL lists.gnu.org. If the user uses something like curl to download the patch, one will not know whether it’s installed or not. I think it won’t be that different.

>> 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)