Re: pull requests

[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.

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