From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Choice of bug tracker Date: Thu, 31 Aug 2023 10:18:27 +0300 Message-ID: <83ttsfel30.fsf@gnu.org> References: <87il9kksqz.fsf@dfreeman.email> <87wmy080kn.fsf@posteo.net> <83v8djcydl.fsf@gnu.org> <87350ndquw.fsf@dfreeman.email> <83350ncbns.fsf@gnu.org> <87cyzrjbd8.fsf@dfreeman.email> <83zg2vav46.fsf@gnu.org> <87o7j99304.fsf@dfreeman.email> <87wmxj27fn.fsf@dfreeman.email> <831qfrptiq.fsf@gnu.org> <57429221-d9be-5791-e975-b3539905e2f6@gutov.dev> <83a5udlj47.fsf@gnu.org> <87a5udk1co.fsf@posteo.net> <835y51kslv.fsf@gnu.org> <7a82c524-1aa1-e755-e377-673ebb107a44@gutov.dev> <83r0nok8s4.fsf@gnu.org> <83ledwk4xi.fsf@gnu.org> <76ecf629-a41a-f6e4-f661-2ef926326d6c@gutov.dev> <83zg2cias7.fsf@gnu.org> <83pm37ie54.fsf@gnu.org> <831qfmhyx3.fsf@gnu.org> <245de638-e6b2-dd8e-ee61-695c4c3da0c7@gutov.dev> <83h6oghixu.fsf@gnu.org> <6ae0b4b0-b2ef-d8de-caed-d647979c2f37@gutov.dev> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8575"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philipk@posteo.net, stefankangas@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov , Stefan Kangas , Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 31 09:19:36 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qbbxo-0001z4-7T for ged-emacs-devel@m.gmane-mx.org; Thu, 31 Aug 2023 09:19:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qbbx3-00035i-W3; Thu, 31 Aug 2023 03:18:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qbbx1-00034p-IK for emacs-devel@gnu.org; Thu, 31 Aug 2023 03:18:47 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qbbx0-0002nl-Go; Thu, 31 Aug 2023 03:18:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=RzVOig6YZ6bQ/rqoOjtX8/MCc90/Ea/aWWYXF6HAu4w=; b=UykiCRsZ7XC+ dY7pIqm6vriIqFMXiGSMOIsfyWDF74ZLiJw6Sw364BJjGR4A2rJviXsu5egoYX+zUmXtfjB6VBeOA ZyUvpwxd2HikqUUmybTPJPdp3CO37qRzMpjjOIgbZX4EfB6Pfhie1et2pCCZJmDMypIEXSdBPVR1d IJC+vgYfyw6/NvhuI34Zkqan/W4PFmL7MdxvcOBW39v//EDvTa0JImOiAgU/gmLhha1aeok0t92GR uIyJPlfJ6XO9/knS3b2eZHGS7ho7V1ohXL5sKrLnZgqoVvBGFyBtrl7X0BtQ1269aSXaYfE2jniR7 fWc7SKO8pyCE4uGrIE9mZg==; In-Reply-To: <6ae0b4b0-b2ef-d8de-caed-d647979c2f37@gutov.dev> (message from Dmitry Gutov on Wed, 30 Aug 2023 23:29:11 +0300) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:309603 Archived-At: > Date: Wed, 30 Aug 2023 23:29:11 +0300 > Cc: philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com, > emacs-devel@gnu.org, manuel.uberti@inventati.org > From: Dmitry Gutov > > >>> . we must have support for features we have now on debbugs > >> > >> As a very reluctant user of Debbugs, I have say this is not a clear > >> description for me. But as mentioned previously, the main features like > >> modifying bug reports from email should either work, or are possible to > >> implement/fix in a reasonable time frame. > > > > We could produce a detailed list of capabilities that must not regress > > wrt debbugs, if that would be useful. The number of those > > capabilities is small. > > That can help. Here's a list of features that I think we want to preserve: . submit a bug report via email . receive bug reports and related discussions via email . give instructions to the tracker via email: - close/reopen/merge issues - add/remove tags from issues - mark a closed bug with the Emacs version where it is fixed . continue discussion of an issue even after it is closed If I missed something important, Michael and Stefan, please add to this list. > > I think it would be unfortunate to ask users to create an account just > > to report a bug and ask questions about it. At least the email > > gateway should be free of this complication (for casual submitters, > > not for the developers and maintainers whom we could ask to register). > > Like I said, it's feasible to set up an email gateway that is one-way. > But juggling responses back to unregistered users and forwarding their > emails again seems (for those discussions to be continued) like a > full-blown mailing list software. Maybe something like that already > exists or could be written without too many complications. I cannot > guarantee that in advance, however. From what I see, none of the "big > and popular" solutions have that kind of feature, even Bugzilla's > "Inbound email gateway". I think this is imperative. An alternative would be to have Emacs commands to let users continue discussions of an issue via some other medium, but frankly, nothing beats email in its easiness, pervasiveness, and the abundance of different MUAs. There must be a possibility to get the users involved in the discussion of bugs they submitted, because frequently we need more info to investigate and decide on solutions. So if this is not trivial, perhaps we should bring someone on board to add such facilities for us, as our special add-on to a good bug tracker which doesn't have that OOTB. Like savannah-hackers or people who manage the GNU mailing lists, for example. > Though at their scale it's likely to result in too much spam anyway. GNU mailing lists have a very efficient system for blocking spam. > >> FWIW, PRs/MRs can be initially disabled, if most of the heavy > >> contributors prefer to stay on the email-driven workflow. > > > > I thought that was the single most important deficiency of debbugs? > > It's a feature that could make it more pleasant/familiar for certain > developers to contribute code, and lead the discussions around such new > code (aka code review). But I wouldn't blame a bug tracker for not being > a code review tool. Bugzilla isn't one either: it seems that projects > using it used something like Gerrit for code review in the past (I have > no experience with it). Bugzilla _can_ be used for patch review, albeit maybe not conveniently enough. And I don't think I'd like a bug tracker that doesn't allow to review code as part of the discussion -- where else will we then do the latter? Maybe I just don't understand what you mean by that, but if you do mean patch review, then how can a good bug tracker possibly lack that?? > > If they aren't, then which capabilities _are_ important to have that > > we don't have on debbugs? > > Just the common bug tracker stuff, mostly related to Web UI (allowing > one to easily read and join a discussion, subscribe to it, unsubscribe, > syntax-highlighted code snippets, linking of issues between themselves, > links between issues and commits, closing issues from commits, assigning > issues to specific developers, ...). Also better working search and a > very visible page "latest active issues/discussions". If those are the main points, perhaps we should also explore the possibility of adding them to debbugs? > I expect a more "modern" bug tracker to result in higher volume of bug > reports (good and bad ones, as discussed previously), reports from more > different kinds of users, possibly resulting in faster bug reports too. > This is just a hypothesis (that a younger user has lower patience on > average), but it seems logical to me. We want to test this theory, but we don't want to give up too many useful features of the current workflow, at least from the maintainer's POV. The challenge is to find a way of satisfying both kinds of needs and requirements with "minimum blood".