Well, I have used both GitLab & Github, and my few cents:(I may have mixed up Github and Gitlab as I use Github much more than Gitlab; please fix me if I’m wrong)
Let try to explain the contribution process on
GitHub/GitLab/BitBucket/etc. briefly.
A contributor wants submit a change.
Note how you again start from a change, not from a report of someissue/bug. As Emacs is a very old and stable project, most of ourchanges fix bugs, not add new features. Therefore, use cases thatbegin with issues are much more important to the workflow and toassessing the utility of the tools.
Any contributor can freely submit a pull request that has the word `Fixes #(Issue number)` and when the pull request is accepted, the issue is automatically closed. because IMO many of the issues were described in exaggerated form
Exaggerated in which sense?
In the sense of representing various aspects of the current flow asabysmally inadequate, and the proposed solutions as no less than apanacea.
Both workflows are inadequate, and overly complicated, but most people will be more familiar to the Gitlab Pull request workflow, and greatly lowers the bar for people who would like to contribute for the first time. I don't like that, mainly because text editing facilities of a browser
are vastly inferior to what I'm used to expect from Emacs.
I understand. That's why I want to figure out whether we can add changes
to GitLab, so (almost) everything also can be done outside the
webbrowser, and from emacs. Or maybe build something like the debbugs
package for emacs.
Personally, I think an Emacs client is almost a must, if we want toconsider something like GitLab seriously.
There are many Emacs clients that tightly integrates with magit; I assume you use magit for managing git repos?
The best one IMO is the official (magit) one:
I’m not sure if commenting on PRs are available; (I don’t use that feature particularly) but I regularly create issues/PRs and push them, fetch them, etc... and notification is also available :-)
It works with Github and Gitlab, and semi-supports Gitea and other forges.
(The initial setup needs the web UI when using Gitlab though; as the Gitlab API doesn’t support create a token unless Github.) Discussing a bug report or a patch in a browser is thus inefficient
and quite frustrating, especially when advanced text editing and
processing is needed. A browser also takes me a step further from the
source code (you don't suggest that I use File->Open of the browser to
browse the code, right?).
Well, mention you mention a commit hash in your comments, the hash
becomes clickable
I didn't mean the commit itself, I meant Emacs sources in general. Ifrequently need to look up source fragments and definitions of variousmacros and structs when I review a patch. Since the browser have noidea where the sources are, and is not in general a good tool forviewing sources of a software project, it is much less helpful here.
With emacs(see magit/forge), this is not an issue anymore! :-) Probably the most complicated about the current bug tracker, at least
from irregular contributor's POV, is interacting to a existing bug:
Where do I send the email to? Who do I CC? How do I set In-Reply-To?
In any decent MUA (certainly with Emacs MUAs), this is almost trivial:the defaults always DTRT. You don't need to think about any of that.On debbugs, I also always forget how to use the control server
commands.
Having a need to use the control command is rare, so I don't thinkthis is a serious disadvantage. Besides, tricky control commands willgive you that with any tool.GitLab fixes that by showing buttons for actions like
close/reopen/label/assign...
There are maybe 2 or 3 people in the Emacs project who use theseactions, so I'm not sure why we should be so interested in them.Yes, I tried to stress the importance of email too. I regret to hear the
email interface of GitLab didn't work for you. I'll have a look whether
I can suggest changes to make the "litter" configurable. But besides
from that, are there any other annoyances you've encountered so far?
I don't know. If the email notifications can be configured to workreasonably well, and could be responded to by email, that might beenough to start a more serious evaluation of the workflow.
As magit/forge supports viewing notifications about the repo in the magit interface; this is no longer an issue anymore. And one more thing: Emacs is I think special in how we work as a
team. Most of the people who respond to bug report and review patches
have write access to the repository, and many of them are trusted to
push changes without approval. It sounds like Gitlab has a very
different team organization in mind, but maybe I'm mistaken.
GitLab shouldn't try to force you in some organisation structure
We'll need to explore this more, I think. It was my impression thatmany defaults there were configured for a certain hierarchicalorganization of the team, which is not what we have here.
|