emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs contributions, C and Lisp (was: Re: /srv/bzr/emacs/trunk r1013


From: Eli Zaretskii
Subject: Re: Emacs contributions, C and Lisp (was: Re: /srv/bzr/emacs/trunk r101338: ...)
Date: Wed, 19 Feb 2014 19:11:57 +0200

> Date: Wed, 19 Feb 2014 08:05:24 +0100
> From: Jorgen Schaefer <address@hidden>
> Cc: address@hidden
> 
> On Mon, 17 Feb 2014 22:29:47 +0200
> Eli Zaretskii <address@hidden> wrote:
> 
> > > There are a few other minor problems for me. For example, my last
> > > foray in adding a patch to Emacs was so scary regarding the amount
> > > of red tape involved in the whole process that I am somewhat
> > > reluctant to commit to doing that regularly.
> > 
> > What red tape?  Emacs is about the most red-tape-less project as you
> > can find, as far as the procedure of admitting a patch is considered.
> 
> If I want to contribute to Emacs, and I want to be good contributor, I
> have the following things to keep in mind:
> [...]

Are you saying that other comparable projects don't have similar
requirements?  Because that'd be definitely not true for the projects
I'm familiar with.

Here are the requirements for GDB contributors:

  
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/CONTRIBUTE;hb=HEAD

Here are the GCC requirements:

  http://gcc.gnu.org/contribute.html

Here's LLVM's (which cover clang):

  http://llvm.org/docs/DeveloperPolicy.html

As you see, Emacs is the norm here, not the odd one out.  In fact, the
Emacs requirements are simpler and fewer than those of other projects.
E.g., GDB requires that every patch be accompanied by a test (which
requires you to install Expect and DejaGnu, and learn how to write
tests), and any user-visible change must come with suitable changes to
the user manual.  You can browse the discussions on gdb-patches list,
where you will see that some changesets are submitted quite a few
times before they are finally approved, something that you will almost
never see here.  As another example, I was recently asked to submit my
changes to Guile in "git format-patch" format, whereas Emacs never
required any bzr-specific procedures for patch submission (as David
points out).

So I really have no idea what is this gripe all about; we just do what
every other project out there does.  I can see how it would be easier
for contributors to just use fire-and-forget methods, but that's not
how projects such as Emacs work.

> Now, do not get me wrong. I am not complaining about these requirements
> (so, re-reading the Wikipedia entry on "red tape" I guess the term was
> badly chosen, sorry, not a native speaker; what's a good term for
> "*lots* of regulation and rigid conformity to formal rules", as opposed
> to "*excessive*"?), but I do think it's important to keep in mind that
> these procedures exist. They do exist for various reasons, usually good
> ones, but they do reduce the appeal of contributing.

If there are better alternatives that are practical, please describe
them.  Since many other projects of comparable size work like we do, I
rather doubt there is a good alternative.  And if so, why do we need
to waste time discussing something that cannot be changed?

> Emacs just thinks it's more important to have those procedures than to
> have more contributors. Which is a perfectly valid decision to make.

Please show some comparable project that made some other decision in
this situation.



reply via email to

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