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: Why Emacs needs a modern bug tracker Date: Sat, 05 Jan 2008 17:57:32 +0200 Message-ID: References: <20080104164454.0A4BD830697@snark.thyrsus.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1199548666 11212 80.91.229.12 (5 Jan 2008 15:57:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Jan 2008 15:57:46 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Eric S. Raymond" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 05 16:58:07 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JBBPS-0004YG-2J for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 16:58:06 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JBBP5-0001jJ-Gc for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 10:57:43 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JBBP1-0001jE-Jc for emacs-devel@gnu.org; Sat, 05 Jan 2008 10:57:39 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JBBOz-0001j2-40 for emacs-devel@gnu.org; Sat, 05 Jan 2008 10:57:39 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JBBOy-0001iz-Un for emacs-devel@gnu.org; Sat, 05 Jan 2008 10:57:36 -0500 Original-Received: from heller.inter.net.il ([213.8.233.23]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JBBOy-0002fN-E2 for emacs-devel@gnu.org; Sat, 05 Jan 2008 10:57:36 -0500 Original-Received: from HOME-C4E4A596F7 (IGLD-80-230-71-78.inter.net.il [80.230.71.78]) by heller.inter.net.il (MOS 3.7.3a-GA) with ESMTP id EOG14101 (AUTH halo1); Sat, 5 Jan 2008 17:57:24 +0200 (IST) In-reply-to: <20080104164454.0A4BD830697@snark.thyrsus.com> (esr@snark.thyrsus.com) X-detected-kernel: by monty-python.gnu.org: FreeBSD 4.7-5.2 (or MacOS X 10.2-10.4) (2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:86187 Archived-At: > From: "Eric S. Raymond" > Date: Fri, 4 Jan 2008 11:44:54 -0500 (EST) > > The difference is scale. GPSD is about 60K lines of code, with a > COCOMO estimate of about 14.2 person-years and about 3 active > developers; normally we only have three or four issues active at once. > Wesnoth is a hair over 100K lines, with a COCOMO estimate of 25.6 > years and 10-12 active developers; over the last year we've gone from > about 500 issues tracked to a bit over 300 (currently 196 feature requests, > 89 bugs, and the remainder marked Fixed but not yet purged). > > Somewhere in the scale range between GPSD and Wesnoth, having an issue > tracker moves from being a dispensable luxury to being an extremely > important tool. [...] > > Now I consider Emacs: 1100K lines, a COCOMO estimate of over 328 > years, and no issue database. I think I think I understand much better > now now why the team has only been able to ship one release in five years. > Trying to converge on a releasable state with as poor a view of the > Emacs bug load as we have must be damn near impossible. You are implicitly assuming here that what is good for a COCOMO-25 project and 10-12 active developers should be also good for a COCOMO-328 project with fewer than 10 developers. Do you have any evidence that this assumption is true, or arguments that would tell me such an assumption is reasonable? > One of the places a real issue database is most concretely useful is when > you're triaging bugs to close on a release. It is *immensely* helpful > in making clear what needs to be done and at what point you are > finished doing it. In Emacs development, we have problems to even find a release manager, let alone someone who will replace Richard as a head maintainer. So having a bug triage system that is significantly better that a flat text file such as admin/FOR-RELEASE is not necessarily the first priority here. Emacs is HUGE. Its immense size is not the only problem: there are many parts in it that require experts in specific areas (GUI display, networking, Lisp infrastructure, email, multilingual text editing, to name just a random few) in order to know what is right and wrong when reviewing patches. Just figuring out how best to organize maintenance of such a large package is a daunting task, to say nothing of actually implementing such a maintenance scheme (which would mean finding and recruiting individuals who could become part of such a team, then making a coherent and cooperative team out of them). It is IMO naive at best to think that switching to more collaborative tools would somehow magically solve these _real_ problems, or even pave a way for their _practical_ solution.