Re: [RFE] Migration to gitlab

[Dmitry Gutov <dgutov@yandex.ru>]

On 17.03.2019 20:05, Eli Zaretskii wrote:
>> savannah.gnu.org looks like a news site
> 
> Are you sure you are looking at the right page?  You should be looking
> here:
> 
>    https://savannah.gnu.org/projects/emacs

I can't help but feel that the mentions of Savannah in this thread are 
disingenuous. After registering there, adding an ssh key and sending the 
membership request for the emacs project, I never went back there, or 
used it for anything else. This is, I suspect, the case for many other 
contributors as well.

So since Savannah's role is very minor, I wouldn't say we need to do 
anything with it. Maybe Emacs' gitlab installation will be the place to 
add the ssh keys, though.

>> I've just read a bit about that. I might be missing some nuances of the
>> process, but right now I don't see how using merge requests vs emails
>> could interfere.
> 
> It doesn't interfere, but it slows down the process for new
> contributors, so doing this stuff quickly is no longer an attainable
> goal.

Wouldn't the said contributors still be able to submit patches over 
email anyway?

On the other hand, the CI could check all the included commits in a PR 
for their authors and the copyright assignments of each. And GitLab 
would show that this particular check failed, which could be more 
accessible for a contributor than reading up on patch submission 
conditions in the documentation.

> 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.

So the closer the CI is to Emacs's home page, and to patch submission 
process, the easier it might be for a new contributor to receive 
automatic feedback on their work.

All of this should be prepended with the work "potentially", but still. 
Gitlab has the ability to improve the experience of both contributors 
and the maintainers, if we make use of the tools it offers.