Re: pull requests

[Dmitry Gutov <dgutov@yandex.ru>]

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.