From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs contributions, C and Lisp (was: Re: /srv/bzr/emacs/trunk r101338: ...) Date: Wed, 19 Feb 2014 19:11:57 +0200 Message-ID: <83k3cr58o2.fsf@gnu.org> References: <87r47bi1e5.fsf@yandex.ru> <52F96284.50507@yandex.ru> <52FAE12B.6060101@yandex.ru> <52FC3BEE.60604@yandex.ru> <52FCD2B4.5080006@yandex.ru> <52FD9F1D.50205@yandex.ru> <83mwhucg1h.fsf@gnu.org> <878ute589i.fsf@fencepost.gnu.org> <83d2iqc84m.fsf@gnu.org> <87wqgxkcr9.fsf@yandex.ru> <834n41db0d.fsf@gnu.org> <52FE2985.4070703@yandex.ru> <831tz5daes.fsf@gnu.org> <8738jlohd6.fsf@yandex.ru> <83txc1bl83.fsf@gnu.org> <5300189A.9090208@yandex.ru> <83wqgv9fbj.fsf@gnu.org> <20140216180712.236069f6@forcix.jorgenschaefer.de> <83sirj9cyp.fsf@gnu.org> <20140217203145.71a849f7@forcix.jorgenschaefer.de> <837g8t8ouc.fsf@gnu.org> <20140219080524.25689b6b@forcix.jorgenschaefer.de> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1392829915 13255 80.91.229.3 (19 Feb 2014 17:11:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Feb 2014 17:11:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Jorgen Schaefer Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 19 18:12:04 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WGAgi-0003LH-F8 for ged-emacs-devel@m.gmane.org; Wed, 19 Feb 2014 18:12:00 +0100 Original-Received: from localhost ([::1]:60840 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGAgi-00009W-0F for ged-emacs-devel@m.gmane.org; Wed, 19 Feb 2014 12:12:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56630) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGAga-00008F-II for emacs-devel@gnu.org; Wed, 19 Feb 2014 12:11:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WGAgV-0003Gi-Sr for emacs-devel@gnu.org; Wed, 19 Feb 2014 12:11:52 -0500 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:40190) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGAgV-0003GV-GF for emacs-devel@gnu.org; Wed, 19 Feb 2014 12:11:47 -0500 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0N19005006AN3200@mtaout24.012.net.il> for emacs-devel@gnu.org; Wed, 19 Feb 2014 19:10:31 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N190054W6DJK100@mtaout24.012.net.il>; Wed, 19 Feb 2014 19:10:31 +0200 (IST) In-reply-to: <20140219080524.25689b6b@forcix.jorgenschaefer.de> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.180 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:169765 Archived-At: > Date: Wed, 19 Feb 2014 08:05:24 +0100 > From: Jorgen Schaefer > Cc: emacs-devel@gnu.org > > On Mon, 17 Feb 2014 22:29:47 +0200 > Eli Zaretskii 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.