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: bug policy (was Re: Release process) Date: Thu, 12 Nov 2015 18:12:25 +0200 Message-ID: <837flnjixi.fsf@gnu.org> References: <8337wdn6uu.fsf@gnu.org> <86611975jo.fsf_-_@stephe-leake.org> <838u65kxly.fsf@gnu.org> <86mvuk4xxd.fsf@stephe-leake.org> <831tbwlext.fsf@gnu.org> <86oaf0b0gj.fsf_-_@stephe-leake.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1447344813 4679 80.91.229.3 (12 Nov 2015 16:13:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Nov 2015 16:13:33 +0000 (UTC) Cc: emacs-devel@gnu.org, john@yates-sheets.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 12 17:13:23 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 1ZwuUv-0004as-FH for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2015 17:13:17 +0100 Original-Received: from localhost ([::1]:47598 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwuUv-0002YV-1U for ged-emacs-devel@m.gmane.org; Thu, 12 Nov 2015 11:13:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47958) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwuUZ-0002XV-MJ for emacs-devel@gnu.org; Thu, 12 Nov 2015 11:13:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwuUW-0000Hh-S8 for emacs-devel@gnu.org; Thu, 12 Nov 2015 11:12:55 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:43674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwuUW-0000HR-FT for emacs-devel@gnu.org; Thu, 12 Nov 2015 11:12:52 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NXP00E00MA98G00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Thu, 12 Nov 2015 18:12:50 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NXP00DTNMD2VN90@a-mtaout20.012.net.il>; Thu, 12 Nov 2015 18:12:49 +0200 (IST) In-reply-to: <86oaf0b0gj.fsf_-_@stephe-leake.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:194238 Archived-At: > From: Stephen Leake > Cc: john@yates-sheets.org, emacs-devel@gnu.org > Date: Wed, 11 Nov 2015 17:06:20 -0600 > > >> During the last feature freeze, there were reminders on this list of the > >> bugs that were deemed release-critical. > > > > That's the last resort. There are gobs of bugs that don't block > > anything, and some of them are left alone for far too long. > > For your definition of "too long". As far as the Emacs project is > concerned, only release-critical bugs have been left "too long". I don't think I agree. A bug can be non-critical, in the sense that we could live with it as we did until now, but still it prevents or interferes with someone's use case. Or maybe we should classify more bugs as release-critical ;-) Speaking about which: what exactly is your definition of criticality? The one we employ now is pretty conservative; for example, a bug that existed in previous releases is not considered release-critical. So, for instance, bug#18997 won't be considered critical, although it involves an abort, something that would be triaged as "critical" in any software maintenance out there. > I don't see how it can be any other way, in a volunteer-staffed free > software project; no one is paid to fix bugs. We cannot force volunteers do anything, but we can try persuading them. If we don't, then what do we need project leadership for? > Another motivation for working on Emacs in general is the desire to work > on a project that has a useful product. But the connection between > fixing bugs and producing a useful Emacs is very tenuous in general; it > is very direct for some bugs (the ones that occur in common or important > use cases), but not for others (obsure bugs that are hard to reproduce). > Clearly lots of people find Emacs useful despite the outstanding bugs. Many bugs in the database are neither obscure nor hard to reproduce. Those are the ones I'm talking about. We could also use more aggressive triage, and clearly mark non-reproducible and obscure bugs as such. Instead, we let them hang in limbo, which probably gives a wrong impression to someone who takes an impartial look at our open bugs. > The bugs in common or important use cases tend to get fixed, because the > package authors are still around to care about them. I think most of our packages don't have such authors around any more. As for the "important" part, it's many times in the eyes of the beholder. A bug in a feature or package you never use will not appear important to you, and it's not easy to understand its importance even when the OP explains that. On balance, I find this kind of approach not useful; a much more useful approach IME is: "do I understand the issue, and can I fix it"? > But we might learn something from triaging the existing bugs; I'll put > that on my list of things to think about while I'm procrastinating > everything else on the list :). Thanks, that will be useful. It's also possible we should use "wontfix" and "unreproducible" tags more aggressively. > > Even a prompt response that just says the bug was reproduced (or not), > > and ideally also with results of some initial investigation and/or > > request from the OP to provide more details or try something -- even > > this would be progress. > > That is the level of support I provide for ada-mode. But that started in > the context of getting paid to use Ada, so it was easy to interpret that > as getting paid to maintain ada-mode. Now that I'm retired, I find > myself much less motivated to maintain ada-mode. Alas, most of Emacs is in this orphaned state. If veteran contributors don't step forward to help more with even the initial analysis of the reported bugs, the job of those few who are involved in bug fixing becomes much harder, and the result will be more bugs left unsolved. If the bug is specific to a platform to which I have no easy access, or involves some software which I cannot or don't want to install, I can only marginally help, mostly by asking questions and suggesting ideas. If someone who does have access to a similar system reproduces the bug and provides its analysis, it is frequently much easier to propose a solution and even come up with a possible patch. Few users can help with such analysis, but most active contributors here have enough knowledge to do so. > The lack of such support for Emacs in general is one reason I learned to > be proficient in elisp, so I could fix any bugs that I encountered in my > Emacs use. That's not an option for every user, but it is what I > recommend to any team that wants to use Emacs; make sure there is > reasonable access to an Emacs guru for this kind of support. I think we have here enough of such gurus, so I'm lobbying for them to become more involved in handling bugs reported to the tracker. The main motivation, IMO, is twofold: (1) solving bugs helps your fellow users, and (2) working on a bug almost always provides an ample opportunity to learn something new about Emacs. > > And then there are small patches submitted there -- review and comment > > will be appreciated. Patches that are no-brainers, e.g., fixing a > > typo or some other obvious mistake, should be pushed if there are no > > comments after a week, say. > > I understand the process; the issue is the motivation. Clearly, it is > far more fun to work on the next Cool Feature, than to chase bugs in > yesterday's Boring Feature :). Emacs features are usually anything but boring. Most of the code was written by first-class experts in design and implementation (myself excluded), so reading and understanding it is a great investment, IMO. > >> There may be other release-critical bugs that I can usefully work on. > > > > The problem IMO is not the release-critical bugs, it's all the rest. > > Exactly why are those a problem? > > Clearly each bug was some sort of problem to at least one user at one > time, but why is it an important problem for the Emacs project in > general? A project that lags on fixing bugs doesn't have a bright future, IMO, for several reasons. For starters, users don't like that for obvious reasons, so such a project most probably loses users it could have retained. A more subtle reason is that working on bugs tends to proliferate knowledge about the project's design and internals, so not working on bugs runs a very real risk of slowly losing that knowledge and increasing the number of areas where no one can make non-trivial changes. We are almost there already: notice the bugs with font handling and with complex script layout. I'm afraid the X display back end, the GTK toolkit, and the Cairo-related code will follow, now that Jan stepped down. These are not obscure unimportant parts of Emacs, far from that. We need to grow experts in those areas soon enough, or we will start accumulating grave bugs that no one can solve. How else do you gain such experts if not by encouraging motivated contributors to start working on bugs in these areas? The only other way of gaining experts is to wait for them to magically materialize, but that doesn't work very well IME. > We don't lose funding by ignoring bugs; what do we lose? We lose our future, I'd say.