emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pull requests


From: Dmitry Gutov
Subject: Re: pull requests
Date: Sat, 28 Mar 2020 19:14:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]