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

[João Távora]

On Thu, Nov 21, 2019 at 3:10 PM Eli Zaretskii <address@hidden> wrote:

> I think we are miscommunicating.  Let me ask you: where do you
> envision the "Emacs GitLab" will be installed? on what server?
>
> The most appropriate one is Savannah,

Yes, I agree

> which will make it be hosted on
> the same machine where our upstream repository lives.  And then who's
> to say that such branches pushed into our GitLab are not part of
> Emacs, like all the scratch branches you and others push now?

Is that question really important? And why does it not apply
to patches as potentially absurd or as harmful as those
branches that are sitting in email bodies of the debbugs
bug tracker and the archives of lists.gnu.org?

> > 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.
>
> That's not the real problem.  The real problem is not to make random
> code appear as being part of Emacs, and part of GNU.

Again, regarding appearance, I think the risk of mistaking
a user's fork on an hypothetical gitlab.gnu.org server for
the work of GNU's developers is very similar to the risk
of doing the same mistake with patches sitting in
https://lists.gnu.org/archive/html/bug-gnu-emacs/.

OK, maybe "very similar" -> "only slightly higher".

But what does that risk amount to, i.e. what are
the consequences of someone making that mistake?

> they are all on the GNU Git server, right?

Yes they are.  More specifically, in the scenario I envision, (and I'm
not an expert on the matter) I think they are in the Git servers
provided by GNU's GitLab instance (or maybe a GitLab instance
specific to GNU Emacs).

João Távora