Re: [RFE] Migration to gitlab

[Tassilo Horn <tsdh@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> P.S. Another feature that would be nice is protected branches[7],
>> which I believe would allow for, e.g., release branches to be closed
>> off for commits (which was discussed recently), and for scratch
>> branches to be rebased (while disallowing rebasing for other
>> branches).
>
> Does this protect only the GitLab's copy of the upstream repository,
> or can we also protect branches on Savannah via this mechanism?

I think protected branches is some administrative feature provided by
GitLab & GitHub and not git itself.

BTW, I'm a Magit user and recently started using Forge for creating
issues and PRs for some 3rd party emacs packages hosted on GitHub, and
its UI is really intuitive and emacsy.  I like it very much.

However, I'm not sure if it would scale for a large project like emacs.
At least the initial pull of issues and pull/merge requests may take
some time.  I've used it with the Magit GitHub repo which is very active
and has many issues/PRs, but those numbers are tiny in comparison to
what emacs would have when all debbugs issues would be GitLab issues.

Also, I'm not sure if it would work out UI-wise at the current point in
time.  AFAIK, Forge simply shows all open issues in a collapsable list,
and it's a different thing if your project has two dozens or several
thousands of open issues.  I'm not sure if you can do some kind of
filtering/searching/scoring right now (other than isearching, of
course).

Another aspect is that GitLab (and GitHub) use Markdown in comments and
discussions, so we'd need to adapt our formatting style, e.g., `symbol`
instead of `symbol', and

```elisp
(foo (bar 'baz))
```

for code blocks, and don't hard-wrap text at some column.  At least you
better do that if the stuff should look good also in the web interface.
(Forge also fontifies that nicely.)

So all in all, I think that GitLab is a good tool, and it's nicely
accessible from inside Emacs using Magit + Forge.  But as long as
there's no test emacs project inside some GitLab instance where all open
debbugs bugs have been converted to issues, every feasibility argument
is just a hypothetical one.

Bye,
Tassilo