emacs-devel
[Top][All Lists]
Advanced

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

Re: [RFE] Migration to gitlab


From: Eli Zaretskii
Subject: Re: [RFE] Migration to gitlab
Date: Sun, 17 Mar 2019 20:05:18 +0200

> Date: Sun, 17 Mar 2019 14:16:36 +0300
> From: Konstantin Kharlamov <address@hidden>
> Cc: emacs-devel <address@hidden>
> 
> 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

> > One thing I think you have possibly overlooked or glossed over is the 
> > copyright requirements for contributions to GNU Emacs. I suspect this 
> > is one of the reasons Emacs is not developed in a similar fashion to 
> > other projects which are based on the use of pull requests etc.
> 
> 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.

> If an arbitrary newcomer out there would consider "Hmm, I have used 
> Emacs and Visual Studio Code, where do I want to contribute"; they 
> easily gonna stop half-way through figuring out how to send a patch, 
> and not gonna contribute to Emacs.

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)

So as you see, being a contributor to Emacs is not easy and takes some
getting used to.  Plenty of reasons for arbitrary newcomers not to be
bothered, whether or not we use Gitlab.  Contributing to Emacs needs a
lot of motivation regardless.  We shouldn't forget that when we
discuss individual issues.



reply via email to

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