From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: Bug tracker choices for Emacs. Date: Tue, 11 Aug 2009 01:36:22 -0400 Message-ID: <87my66ap49.fsf@canonical.com> References: <87ws5ij2rw.fsf@canonical.com> Reply-To: Karl Fogel NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1249969013 28225 80.91.229.12 (11 Aug 2009 05:36:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Aug 2009 05:36:53 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 11 07:36:46 2009 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 1Mak2P-0000i9-Me for ged-emacs-devel@m.gmane.org; Tue, 11 Aug 2009 07:36:46 +0200 Original-Received: from localhost ([127.0.0.1]:54945 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mak2O-0001bp-CL for ged-emacs-devel@m.gmane.org; Tue, 11 Aug 2009 01:36:44 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mak29-0001bJ-Mw for emacs-devel@gnu.org; Tue, 11 Aug 2009 01:36:29 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mak28-0001aS-1D for emacs-devel@gnu.org; Tue, 11 Aug 2009 01:36:28 -0400 Original-Received: from [199.232.76.173] (port=54143 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mak27-0001aP-OR for emacs-devel@gnu.org; Tue, 11 Aug 2009 01:36:27 -0400 Original-Received: from adelie.canonical.com ([91.189.90.139]:54600) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mak27-00057s-74 for emacs-devel@gnu.org; Tue, 11 Aug 2009 01:36:27 -0400 Original-Received: from hutte.canonical.com ([91.189.90.181]) by adelie.canonical.com with esmtp (Exim 4.69 #1 (Debian)) id 1Mak25-0007eK-HO; Tue, 11 Aug 2009 06:36:25 +0100 Original-Received: from cpe-72-225-235-182.nyc.res.rr.com ([72.225.235.182] helo=kfogel-work) by hutte.canonical.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Mak25-0003ya-9F; Tue, 11 Aug 2009 06:36:25 +0100 In-Reply-To: (Stefan Monnier's message of "Thu, 06 Aug 2009 12:19:12 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:114034 Archived-At: Stfan Monnier and Glenn Morris both asked questions, in separate mails; I'll answer them together in this one mail. Stefan Monnier writes: >> It can be completely operated by email: >> https://help.launchpad.net/Bugs/EmailInterface > > Can we make bug-gnu-emacs@gnu.org redirect to it (i.e. accept email > submissions from any random user without prior registration, which is > *very* important). Currently it requires a registered user. I'm not sure that's a strong policy; if we had other anti-spam measures (such as requiring a particular string to be in each mail body), then maybe we could do away with that. > Can we install it in debbugs.gnu.org? You could, but I meant hosting at Launchpad.net. Running an instance of Launchpad involves all sorts of production issues; Canonical is already bearing that cost, and I certainly am not volunteering to duplicate the cost anywhere else :-). > Can it be operated from Rmail (i.e. MUAs without support for GPG signing)? I think you can comment on bugs but not create them, via unsigned mail. >> - Not really operable via the web -- just read-only operations. >> This is huge. > > This is not huge for me, but it's clearly a shortcoming. I should have said "huge for most users". >> - Does not do automatic duplicate-finding when a new bug is submitted. >> Launchpad bugs does, and it's a real gift. (Actually, from reading >> the documentation, it's not clear to me how to handle duplicates in >> debbugs at all -- there doesn't seem to be a simple way to say >> "Close bug #Y because it's a duplicate of #X". And the mere fact >> that one has to read the documentation is already a disadvantage.) > > It's called "merge". It's worked OK for me. Odd; I saw that page, but what I read there didn't seem to be about duplicate bugs as I understand them. http://emacsbugs.donarmstrong.com/server-control#merge "Before bugs can be merged they must be in exactly the same state: either all open or all closed, with the same forwarded-to upstream author address or all not marked as forwarded, all assigned to the same package or package(s) (an exact string comparison is done on the package to which the bug is assigned), and all of the same severity. ..." >> - Interface can be a bit unintuitive ("Toggle useless messages", for >> example; or consider the number of choices one must make before >> doing a simple search). >> - A bit Debian-centric. See the long list of checkboxes for >> distributions in the search form on the front page, for example. > > You mean the Web interface? Yes, the web interface is not great. I meant the web interface. It goes without saying that the email interface is unintuitive, but that's okay, as the people who would use that are looking for an interface aimed at experts, not newcomers. Glenn Morris writes: > Karl Fogel wrote: > > > So, are we happy with debbugs? > > I'm not. Some of my reasons are listed here: > > http://emacsbugs.donarmstrong.com/cgi-bin/pkgreport.cgi?pkg=emacsbugs.donarmstrong.com > > The main problem is, it's effectively unmaintained, and the Emacs > developers have no administrative access. A move to a gnu machine that > would hopefully fix these issues has been waiting for the best part of > a year. Launchpad is certainly maintained, but it would still be on non-GNU servers (unless GNU wanted to run an instance, which would be a huge undertaking and is not what I was suggesting). > > - Does not do automatic duplicate-finding when a new bug is submitted. > > Launchpad bugs does, and it's a real gift. > > What does "automatic duplicate-finding" mean? When you file a new bug, the system first searches for bugs that look like it, to cut down on the number of duplicate filings (which otherwise is usually large). > > (Actually, from reading the documentation, it's not clear to me how > > to handle duplicates in debbugs at all -- there doesn't seem to be a > > simple way to say "Close bug #Y because it's a duplicate of #X". > > As pointed out, the merge/forcemerge commands do this. Yup. See my comments above, but obviously once one understands the commands, this is what they do. > Questions I would ask of a bug tracker: > > How well maintained is it? How many developers are there, and how > responsive are they to feature and problem requests? Hard to say how many developers there are, since Launchpad is free software. Estimate 3-5 right now, since there are some full-time people on it. > If we want to customize the way it behaves for Emacs, is there someone > who can do this for us, or help us do it to our local copy if it's not > a change appropriate for the tracker in general? Failing that, how > easy is it for an outsider to modify the code? It's a free software project. For code to get deployed on Launchpad.net, it obviously has to be absorbed into upstream and go through the rollout process, so that means no quick-n-dirty tweaks. > Can the Emacs developers get full administrative access? As in root? No. > How does it handle spam? Unregistered users must be able to submit > Emacs bug reports. Therefore there will be spam. Some kind of human > moderation is required. Can this be integrated into the mail flow? The > current emacsbugs method (closing spam bugs after the fact) is a waste > of effort, and does not deal with spam added to existing bugs. The > state of emacsbugs is shameful in this regard (again, see Bug#750 as > an example). I don't think it deals well with this (see above; it could be improved). Right now its solution is pre-registered sender addresses and GPG-signing. > How does it handle the CC problem? Currently, when people report a new > bug, they need to use X-Debbugs-CC rather than CC, lest each reply > create a new bug. Often, they don't know they need to do this. Hence, > bug 4065 and 4066, for example. Tracking of references/message-ids > might fix this? Gosh. I've never noticed any CC problem, so I guess it handles this okay, but I'm not 100% sure. > If it sends out admin messages, can these be directed to a separate > mail list from the normal bug list? Not sure what the core question is here. > Does it suppress duplicates? This may need message-id tracking. Again, not sure what the question is. Does it fold duplicate mails? I don't know. > Can it automatically subscribe the bug reporter to all followup discussion? I think it does. > Does it obfuscate addresses in the web interface? Right now it doesn't need to, because it uses usernames instead. > How good is the search function? The debbugs one is not great. The search functionality is good, IMHO. (I'd be more specific, but it might be easier to just try it and see what you think.) > Your best bet is probably to just set up a test-bed for people to play > with, and see if they like it... Based on the above, I'm not going to pursue it right now. There are too many changes that would be necessary, and other things (like the Bazaar switchover) are more pressing to me. This discussion is in the archives now. If we ever want to revisit it, I hope we'll remember to start here. -Karl