From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: debbugs tracker builds character Date: Thu, 21 Jul 2016 10:13:50 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87wpkf6pup.fsf@lifelogs.com> References: <4hd1rw1ubr.fsf@fencepost.gnu.org> <83vb50wxhv.fsf@gnu.org> <87y49vz4cg.fsf@acer.localhost.com> <87twg2g86g.fsf@lifelogs.com> <83eg76n5h5.fsf@gnu.org> <87y45eeoor.fsf@lifelogs.com> <577D42BB.1020500@cs.ucla.edu> <87oa694rfw.fsf@russet.org.uk> <837fcxlbay.fsf@gnu.org> <87lh1d2wg5.fsf@russet.org.uk> <83eg75jk5h.fsf@gnu.org> <87lh1cb6p0.fsf@lifelogs.com> <87oa5sa176.fsf_-_@lifelogs.com> <874m7kmkcm.fsf@gmx.de> <871t2o6t94.fsf@gmx.de> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1469110630 911 80.91.229.3 (21 Jul 2016 14:17:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Jul 2016 14:17:10 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 21 16:17:02 2016 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 1bQEmb-0000WG-5F for ged-emacs-devel@m.gmane.org; Thu, 21 Jul 2016 16:17:01 +0200 Original-Received: from localhost ([::1]:41081 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQEma-00032U-C1 for ged-emacs-devel@m.gmane.org; Thu, 21 Jul 2016 10:17:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33885) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQEjp-0001Eb-SS for emacs-devel@gnu.org; Thu, 21 Jul 2016 10:14:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bQEjl-0008FA-Df for emacs-devel@gnu.org; Thu, 21 Jul 2016 10:14:08 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:60056) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQEjl-0008Ey-2y for emacs-devel@gnu.org; Thu, 21 Jul 2016 10:14:05 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1bQEjj-0007DM-Mm for emacs-devel@gnu.org; Thu, 21 Jul 2016 16:14:03 +0200 Original-Received: from c-98-229-60-157.hsd1.ma.comcast.net ([98.229.60.157]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Jul 2016 16:14:03 +0200 Original-Received: from tzz by c-98-229-60-157.hsd1.ma.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Jul 2016 16:14:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 116 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-98-229-60-157.hsd1.ma.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cancel-Lock: sha1:hKY+GDYM+M4TyrL68m1O5SzX81M= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:205953 Archived-At: On Wed, 20 Jul 2016 20:48:07 +0200 Michael Albinus wrote: MA> Anyway, I believe this ship has sailed years ago. If somebody wants to MA> replace debbugs, (s)he must do heavy lobbying for it. Don't know whether MA> it could succeed, and whether it is worth the trouble. The better MA> approach seems to be to exploit debbugs to its best. IMO. ... MA> MA> That thread is the 10 years old discussion on emacs-devel, which ended MA> up in deciding for debbugs. And I find the reasoning for using email MA> still convincing. I don't care about the underlying bug tracker as much as I care about getting things done. This is my underlying reason to start a discussion. (Right now, I can set up an Emacs mirror on Github, do a pull request there and accept comments there. It would work great and I can merge the branch back into the Emacs Git repo. The only reason I haven't is political: I believe the maintainers should guide the tool choices.) >> The bug tracker should be aware of repositories, branches, commits, >> contributors, and ticket links or mentions in commit messages. >> Contributors should be able to tag and notify each other. Markdown etc. >> should be well supported. Inline code comments should be easy, and >> linked to a commit (so an updated commit can resolve the comment). This >> is just the essential stuff. MA> Some of this exist already (tags), maybe underdocumented. For the rest I MA> must at least sleep one night :-) It's hard to do the things I listed (especially VCS integration) with the current Emacs bug tracker. These things were not so important 10 years ago. I think as a team, we have to be willing to reassess our tool choices at least every 10 years (e.g. Bazaar and then Git were major tool changes but didn't change the Emacs project). As a practical choice, I'd rather lobby to use better tools than to write them ourselves: it wastes resources, and I don't think bug and issue tracking is our strongest area. I'd rather have you (Michael and others) get some sleep or work on Emacs itself. MA> A practical counter-argument: do you believe that debbugs is *such* bad MA> that the vast majority of Emacs developers will follow you for a new bug MA> tracker? I'm not a debbugs missionary, but in my daily work I found it MA> sufficient. Somehow. Well, I'm partly basing my view on the vitality of ELPA packages on Github. There are hundreds (some end up on the GNU ELPA, some hosted elsewhere). I've contributed to several like https://github.com/Silex/docker.el and https://github.com/flycheck/flycheck and the process is better for the reasons I've described. Will the Emacs developers follow me? I'd love to see them use a better process. I'm happy to concede I'm wrong and the current process works fine, but the evidence leads me to believe it can be improved with better tools (similar to the evidence in favor of Git when we were using Bazaar). I'm not going to spend the next 6 months talking about it; I'd rather know if the maintainers (Eli and John) and other core developers are willing to consider Gitlab or something similar. I think I've stated the case clearly, and quite a few of us have experience with more powerful bug/issue trackers so we know what we're missing. If the decision is "no, we'll move on with whatever marginal improvements to debbugs we can make" then I'll come back to the topic in another 10 years :) On Wed, 20 Jul 2016 16:43:08 -0400 Stefan Monnier wrote: >>> Yes, I agree that this is the crucial point. That's my motivation for >>> developing BugIt (https://gitlab.com/monnier/bugit). >> IMHO it's not that important a goal. The old-timers have lived without it >> for a while, and the youngsters have no idea that it's something to >> be desired. SM> The more I use BugIt, the more I find it important to be able to query SM> the bug database while offline. Being able to queue actions so they're SM> executed when I get online is not too terrible, but it's not really SM> good enough. I don't disagree entirely, but in 2016 disconnected operation is much less common than in 2006. There are tools that can synchronize database replicas seamlessly. Fundamentally, though, I think the focus of bug and issue tracking has shifted from individuals working on fixes, to teams collaborating and reviewing each other's work, with the ability to include and notify the entire community. IMHO this is the true value in Github and its competitors, and the biggest reason why they've seen so much adoption. On Wed, 20 Jul 2016 16:40:01 -0400 Stefan Monnier wrote: SM> I think I'm starting to see what you mean. You're talking about a tight SM> integration where a pull-request is also itself an issue, so the comments SM> can be directly on the patch itself. As opposed to having issues and SM> pull-request be two separate things that can refer to each other via SM> an indirection. Yes. Actually Github has both of these right now. When pull requests are not true issues, they tend to be associated with issues: sometimes 1-to-N and sometimes N-to-1. People have different workflows, so it's good to have flexibility built into the model. Sorry if this seems ambivalent; it's really a degree of creative freedom that users appreciate. On Wed, 20 Jul 2016 17:25:33 -0400 Eric Abrahamsen wrote: EA> A suggestion from a part-time package maintainer: make EA> `report-emacs-bug' prompt for a package, and offer the results of EA> `featurep' as completion. If the user picks a package that only exists EA> in ELPA, email the package maintainer with the bug report. That's a really good suggestion, regardless of the underlying bug tracker. Thanks for the thoughtful comments Ted