> Sending patches via email is only one requirement. There are other
> requirements peculiar to Emacs, which will not go away if we switch to
> another patch submitting system. Some of these requirements, each and
> every one of them flagged at some point as an obstacle for newcomers:
>
> . code submissions should include documentation
> . commit log messages should be formatted in a certain way
> . bug numbers should be referenced in log messages
> . US English conventions in writing comments and documentation
> (spelling, two spaces between sentences, etc.)
> . we require copyright assignments for accepting changesets larger
> than about 15 original source lines
> . we have peculiar rules regarding the branch were certain changes
> should be pushed (affects the branch against which contributors
> should prepare patches)
> . very elaborate coding and documenting conventions (their
> description takes around 900 lines in the ELisp manual)
At least some of these checks could be automated on a CI. And the author
of a random PR would get an overview of its compliance automatically.
Also when someone creates a PR (or Issue), there can be template text (with checkboxes, etc) stating these points, so the author has a direct reminder to improve the quality of his PR or Issue before he sends it.
And if he does not check all the checboxes and submit anyway, then the maintainer's job is easier because he already knows the missing parts.
I believe this whole discussion is basically this: the ones who are used to a gitlab workflow see the obvious benefits, and the ones who only use the email workflow don't see what's so great about it because they always find a manual/configuration-heavy way to achieve the same.
I think the manual/configuration-heavy way is not very smooth and makes _you_ work instead of the tools, when this effort could be better spent improving Emacs.
Kind regards,
Philippe