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: New maintainer Date: Sat, 03 Oct 2015 11:04:15 +0300 Message-ID: <83oagg4buo.fsf@gnu.org> References: <560CCEBA.9080607@online.de> <874miapdhs.fsf@openmailbox.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1443859488 1509 80.91.229.3 (3 Oct 2015 08:04:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 3 Oct 2015 08:04:48 +0000 (UTC) Cc: johnw@newartisans.com, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 03 10:04:33 2015 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 1ZiHo0-0001CM-39 for ged-emacs-devel@m.gmane.org; Sat, 03 Oct 2015 10:04:32 +0200 Original-Received: from localhost ([::1]:37366 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZiHny-00043P-Rp for ged-emacs-devel@m.gmane.org; Sat, 03 Oct 2015 04:04:30 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41916) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZiHnu-00042E-Qm for emacs-devel@gnu.org; Sat, 03 Oct 2015 04:04:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZiHnr-0004kn-Jc for emacs-devel@gnu.org; Sat, 03 Oct 2015 04:04:26 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:58004) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZiHnr-0004kb-CZ; Sat, 03 Oct 2015 04:04:23 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NVM00100X0OUX00@a-mtaout23.012.net.il>; Sat, 03 Oct 2015 11:04:21 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NVM0019YX39UV00@a-mtaout23.012.net.il>; Sat, 03 Oct 2015 11:04:21 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 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:190775 Archived-At: > From: Richard Stallman > Date: Fri, 02 Oct 2015 21:36:28 -0400 > Cc: emacs-devel@gnu.org > > GNU Emacs is part of the GNU Project, which is a technical project > with a specific political aim: software freedom for all users. This > goal includes all the software they use, not just the specific programs > we develop. > > The GNU Emacs maintainer's responsibility is to take charge of Emacs > on behalf of the GNU Project, and produce the best possible GNU Emacs > -- which means, the one that advances our aim the most. > > Mostly, making Emacs better is a matter of practical improvements, but > there are some exceptions. The maintainer's responsibility includes > some tasks to support the GPL, both practically and politically. It > includes getting copyright papers from contributors so we can enforce > the GPL. It includes making sure dynamic loading resists GPL > violation. It includes putting some GNU Project political statements > into Emacs. It includes making sure nothing in Emacs disagrees with > them. An Emacs maintainer has to be willing to undertake this part of > the responsibility as well as the politically neutral bulk of the > responsibility. > > The maintainer's job does not include personal political statements. > Maintainers don't have to say they agree with the GNU Project's > political positions, they just have to implement them wholeheartedly. > > However, a maintainer shouldn't publicly oppose our positions. Thanks for that summary, Richard. In my personal experience, what you describe is not the most important part of the decision a candidate or a nominee should make before agreeing to volunteer. He or she should indeed make sure they are OK with all of the above, but I believe most of us are anyway. The practical implications of the above are more or less no-brainers: performing the few implied duties is simple, even mechanical, and some of them will rarely if ever be needed at all, except in some extreme and improbable situation (like if someone declares they no longer want to be part of the GNU Project, forks Emacs and takes most of the contributors with them). Yet another part is just agreement to some principles, and has not practical implications beyond the fact of the agreement itself. IOW, this, what I call "the FSF side", of being the maintainer is not the hard part of the decision to become one, nor something most of the others should consider when they decide whether a candidate gets their vote of confidence. The hard part, IMO, is what does it mean "to produce the best possible Emacs"? What's the translation of this to everyday's practice? Perhaps we should consider this part of the job description before we start nominating candidates and volunteering. Emacs is so large that its maintenance is IMO qualitatively different from almost any other package out there. There are maybe a dozen distinct large areas of expertise in the C core, dozens of such areas in core Lisp infrastructures, and hundreds of them on the application level. Each one of these comes with its own non-trivial domain-specific knowledge, its own algorithms, its own do's and dont's. No single person nor a small (2-3) number of people could ever cover all that turf in any reasonable way. By contrast, a head maintainer seems to be expected to be the final authority for making decisions on changes in any particular area, and also on design and implementation of both significant and insignificant new features. So, given this seemingly unsolvable contradiction, what do you, the crowd, expect of the new maintainer? What "job description", in addition to what Richard wrote, would you propose if you were tasked with the job of finding the candidates? E.g., how many hours a week should that person be available for working on Emacs? Which talents and personal traits should he or she possess? Etc. etc. I'm not writing this to solicit a barrage of suggestions for such a job description, so please hold off your fast-typing fingers. I'm writing this to suggest that each one of us should take a moment to think about these expectations, and decide who or what would we want that next "maintainer" to be. That's because I'm not sure all of those who participated in this thread have the same things in mind when they express their opinions about who might be a good maintainer. Then look around and see if there are any persons who fit the bill here. Then you could perhaps provide some rationale for why you think this or that person could be a good candidate. HTH