Re: pull requests

[Dmitry Gutov <dgutov@yandex.ru>]

On 28.03.2020 04:46, Richard Stallman wrote:
> [[[ 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 section is literally "contributions under consideration",
> 
> 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.

> 								   why would
>    > anyone think it's the project code already?
> 
> Why wouldn't anyone thing so?  Are you proposing to display a message
> of explanation whenever someone tries to view the code in a pull request?

99% of the users who would be looking at them, would be doing so through 
the web interface of the force software. And at that web page it would 
be made apparent that the user is looking at a pull request.

> Suppose A sends B a URL pointing to a branch with non-installed
> patches.  If A doesn't warn B; 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.

When you were talking about hiding PRs from non-developers, you meant 
hiding in the web interface, right? Because it would be hard to hide 
them in the mailing lists, for example, considering they're all public.

Anyway, if the branch is not called master or emacs-xx, then it's 
relatively obvious that it contains some code that is yet to incorporated.

> This is asking for big trouble.  Versions of Emacs that by policy
> we should not be distributing could start being distributed in that way,
> and no responsible person would ever be asked whether to do this.

As per above, I think it would be hard to mistake a non-official branch 
for an official one. But that brings us to the question of whether we 
would allow unauthenticated users to create new branches in our forge.

The previous discussion concluded on "probably not", and then the 
situation is not different from the current one: pull requests (or 
"merge requests") would be created only by the current developers who 
have commit access.

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.

Also, if any branches in our repo end up containing really problematic 
code, I'm sure that can be dealt with on a case-by-case basis.