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 22:19:42 +0200 Message-ID: References: <20080104164454.0A4BD830697@snark.thyrsus.com> <20080105182456.GR30869@thyrsus.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1199564389 26670 80.91.229.12 (5 Jan 2008 20:19:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Jan 2008 20:19:49 +0000 (UTC) Cc: esr@snark.thyrsus.com, emacs-devel@gnu.org To: esr@thyrsus.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 05 21:20:10 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 1JBFV0-00032r-8p for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 21:20:06 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JBFUd-00070B-Ev for ged-emacs-devel@m.gmane.org; Sat, 05 Jan 2008 15:19:43 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JBFUY-0006xN-V2 for emacs-devel@gnu.org; Sat, 05 Jan 2008 15:19:38 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JBFUX-0006u6-Dx for emacs-devel@gnu.org; Sat, 05 Jan 2008 15:19:38 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JBFUX-0006ts-5i for emacs-devel@gnu.org; Sat, 05 Jan 2008 15:19:37 -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 1JBFUW-0007DH-Q9 for emacs-devel@gnu.org; Sat, 05 Jan 2008 15:19:37 -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 EOG92534 (AUTH halo1); Sat, 5 Jan 2008 22:19:34 +0200 (IST) In-reply-to: <20080105182456.GR30869@thyrsus.com> (esr@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:86226 Archived-At: > Date: Sat, 5 Jan 2008 13:24:56 -0500 > From: "Eric S. Raymond" > Cc: "Eric S. Raymond" , emacs-devel@gnu.org > > First, the size of a project's bug load is driven by the square of > LOC. This is because most bugs are clashes between assumptions mode > in differing parts of the code. You are assuming that all parts of the code are being developed, it seems. That's not what happens in Emacs, probably due to its age and the fact that core features are developed/refactored only very seldom, or not at all. In any case, unless we lose a huge amount of bugs due to lack of tracking, the amount of bugs in Emacs is not consistent with the quadratic curve hypothesis, let alone higher powers. And the bugs reported through the various Emacs channels do not suggest that we leave such a large amount of bugs without fixing, or else we'd have lots of repeated bug reports. > > 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. > > Perhaps not. But it certainly couldn't hurt. ``Couldn't hurt'' is not a good argument when deciding where to apply limited resources. Like in code optimization, you first try to identify the hot spots, and then go for those spots first. But as I said elsewhere, let's have a bug tracker happen, and see where it gets us. I have seen enough talking on this issue; if there's energy left in those who think a bug tracker will make a difference, let's see it in action and argue later. > And, maybe, if bug-triage weren't quite so much like having a herd > of elephants stampede over your testicles, a release manager might > be just a *leetle* easier to find? You are certainly not stupid enough to believe I'm talking theoretically here. I actually was an Emacs release manager once, and I don't recall having any special problems managing the bug queue, certainly not something that could be described as elephants stampede over my testicles. What took most of the time during the release is _fixing_ the bugs, not tracking them. If your scaling assumptions are true, I don't see how they can be supported by my own experience of participation in Emacs maintenance.