Re: "If you're still seeing problems, please reopen." [Was: bug#25148:]

[João Távora]

On Thu, Nov 21, 2019 at 2:49 PM Eli Zaretskii <address@hidden> wrote:
>
> > From: João Távora <address@hidden>
> > Date: Wed, 20 Nov 2019 20:12:28 +0000
> > Cc: Lars Ingebrigtsen <address@hidden>, Óscar Fuentes <address@hidden>,
> >       emacs-devel <address@hidden>, Richard Stallman <address@hidden>, 
> > Dmitry Gutov <address@hidden>
> >
> > > > Well, yeah, but from the contributor's side the process is very
> > > > similar. Apart from not being able actually merge the PR
> > > > to master, he changes the PR's branch in the very same
> > > > ways as I (the developer) described in my previous email.
> > >
> > > That branch _is_ the problem.  You don't want that to be a branch in
> > > our upstream repository.
> >
> > Why don't you?
>
> Because then anyone could push code to our main repository, even
> without having write access, and we don't want to host code we didn't
> eyeball in advance: it might include stuff we don't want to have
> anywhere close to Emacs, or to GNU in general.

Right, certainly.  But in the GitLab/GitHub model, there is that
main repository, which is your duty to protect, and also
isolated from it, one for each "JR Random Hacker", a _fork_
(maybe Gitlab calls  it a "clone") that JR can randomly hack
away in.  That fork lives in the Emacs GitLab instance.  It
does take some disk space there, but that's pretty much
it as potentially unwanted impact goes.

JR's code is never merged  to the main repository without your
or some developer's explicit approval.  GitLab has a
sophisticated permissions system that states exactly what an
owner, a maintainer, a developer and a potential contributor
can do to the main repository.

The way it would most closely reflect our current model is:

* everybody can create issues (i.e. bugs) in the main
   repository
* everybody can fork the main repository
* everybody can make pull requests to the main repository.
* every developer that currently has write access can
  change and eventually merge the pull requests from
  everybody else.

We could enhance this later, of course, to reflect another
organization within developers, for example.

João