From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: John Wiegley Newsgroups: gmane.emacs.devel Subject: Re: New maintainer Date: Mon, 05 Oct 2015 12:02:50 -0700 Organization: New Artisans LLC Message-ID: References: <5610207A.2000300@harpegolden.net> <83fv1r3gzp.fsf@gnu.org> <83bncf3f9k.fsf@gnu.org> <5610E0BC.8090902@online.de> <83si5r106e.fsf@gnu.org> <831td9z18h.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1444072903 4079 80.91.229.3 (5 Oct 2015 19:21:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 5 Oct 2015 19:21:43 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 05 21:21:42 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 1ZjBKQ-0000xw-14 for ged-emacs-devel@m.gmane.org; Mon, 05 Oct 2015 21:21:42 +0200 Original-Received: from localhost ([::1]:47316 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjBKP-0005uZ-G5 for ged-emacs-devel@m.gmane.org; Mon, 05 Oct 2015 15:21:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57428) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjBJY-0004fu-2B for emacs-devel@gnu.org; Mon, 05 Oct 2015 15:20:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZjBJT-0005pz-41 for emacs-devel@gnu.org; Mon, 05 Oct 2015 15:20:48 -0400 Original-Received: from mail-pa0-x22b.google.com ([2607:f8b0:400e:c03::22b]:36795) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZjBJS-0005pH-Ss for emacs-devel@gnu.org; Mon, 05 Oct 2015 15:20:43 -0400 Original-Received: by pablk4 with SMTP id lk4so184108762pab.3 for ; Mon, 05 Oct 2015 12:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:in-reply-to:date:organization:message-id :references:user-agent:mail-followup-to:mime-version:content-type; bh=7lynaOxAnoAM/58VJznAXkNU68dgXqQJJyvBr7bb9f4=; b=RHisWdLppZOZpNSIA1GKuPltD4m2Yv5RjM+3HTWaEn3rG7diM3JnH0k9TQsBYhwnhP argDSxIn+nf9cmDe+KR8Ttp7TW4mRM6ZgKTYEWdN2UbiVN2wRvonOkXuVhOTZr5reu8J ddsXk7l/XpxPdkJOWwbjBIXsjDCKVxAXZiLIu8E3rQezGg+2qky0ES0l8twnVOw1RcEZ 31UBcBy6e5Ye2b37zpmfp8yrV80QPWsorPacuqsG+UDClxUXLgZ8hG9Oegb7NpQlOfOc ORRQCrf+FBtXltQdQ9I5hNXykmos9mDa6MBmLmy46WYQ4++ZKp2TtYpW7IJxbo6E7BgP noag== X-Received: by 10.66.144.199 with SMTP id so7mr41849527pab.42.1444072841947; Mon, 05 Oct 2015 12:20:41 -0700 (PDT) Original-Received: from Vulcan.local (76-234-68-79.lightspeed.frokca.sbcglobal.net. [76.234.68.79]) by smtp.gmail.com with ESMTPSA id l16sm29083744pbq.22.2015.10.05.12.20.40 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 05 Oct 2015 12:20:40 -0700 (PDT) Original-Received: by Vulcan.local (Postfix, from userid 501) id 92078F074A1C; Mon, 5 Oct 2015 12:20:39 -0700 (PDT) In-Reply-To: <831td9z18h.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 05 Oct 2015 20:14:38 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin) Mail-Followup-To: emacs-devel@gnu.org X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::22b 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:190959 Archived-At: >>>>> Eli Zaretskii writes: > The issue is merely how to organize the maintainership, and how to define > the division of responsibilities with c-maintainers, if there will be such. This is a great question, and one I've been pondering myself, since the most pressing variable for me in all of this is time. Where I think I can contribute best is the bigger picture, or "meta issues": weighing in on technical discussions, making higher-level decisions about technical direction, keeping an eye on user experience within the community and the quality of Emacs resources, coordinating volunteers, ensuring proper legal forms are maintained, liaising with the FSF, and assisting other maintainers so they don't burnout and receive the help they need. What I probably don't have enough time for is giving all the issues, code submissions, and discussions on emacs-devel, the depth and refinement they deserve. This is where I've noticed Eli (and certainly Stefan) doing an excellent job. I'm quite impressed by their energy and involvement. I would need such people to make this job even possible within the constraints of my life. I also think that detail-level maintenance is far more likely to induce burnout, since the flood at that level can be intense. Seeing the number of replies by Eli and Stefan in the past few weeks has been impressive to say the least, and requires a special kind of interest and energy to maintain. How do we best support them? How do we find more hands to make lighter work for our stalwart contributors? Meanwhile, I want to think about the road leading to Emacs 26, and to work with Eli, and the community as a whole, on what makes the most sense in terms of what we have now, and what we want Emacs to become. For example, we have compute-intensive applications -- such as Gnus -- that cannot take advantage of the additional power offered by multi-core CPUs. How do we add concurrency without increasing our maintenance burden due to impossible-to-reproduce bugs, race conditions, and terrible error messages (a Backtrace, but from which thread?). It will require significant collaboration to decide exactly what we want, and what Emacs needs, from such features. Another area we're falling behind in is the type of IDE features that are taken for granted in special-purpose editing environments, such as effortless code browsing, refactoring, and more interactive debugging. The things you can do when editing Java and Javascript are downright impressive, and I see no reason Emacs can't compete better here. It would be hard to care about these issues in sufficient depth if the job of project maintenance also required keeping an eye on every issue and technical discussion. I think having co-maintainers (maybe several) who are good at detail is absolutely essential to getting this job done. John