emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFE] Migration to gitlab


From: Dmitry Gutov
Subject: Re: [RFE] Migration to gitlab
Date: Tue, 19 Mar 2019 02:52:17 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]