[Top][All Lists]

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

Re: pull requests

From: Dmitry Gutov
Subject: Re: pull requests
Date: Mon, 30 Mar 2020 20:49:20 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

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

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.

reply via email to

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