From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Choice of bug tracker Date: Fri, 1 Sep 2023 03:29:10 +0300 Message-ID: <8f500cee-f136-fdc6-aaa5-960bbeceeaae@gutov.dev> References: <87il9kksqz.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> <83ttsfel30.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12024"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: philipk@posteo.net, emacs-devel@gnu.org To: Eli Zaretskii , Stefan Kangas , Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 01 02:30: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 1qbs3W-0002v8-Gx for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Sep 2023 02:30:35 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qbs2O-0003Ns-IW; Thu, 31 Aug 2023 20:29:24 -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 1qbs2M-0003Nd-Bt for emacs-devel@gnu.org; Thu, 31 Aug 2023 20:29:22 -0400 Original-Received: from wout1-smtp.messagingengine.com ([64.147.123.24]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qbs2I-00023q-OO; Thu, 31 Aug 2023 20:29:22 -0400 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 0B3BF32008C0; Thu, 31 Aug 2023 20:29:14 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 31 Aug 2023 20:29:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1693528154; x=1693614554; bh=dig2Nah7S0wFxy5vubRv0w4mJnfnNG420O3 OX8npovo=; b=ADDF8t4a4A63hfIdyLTtHudWDmUWgwKEXrVUjmakkWk8cka3eab aZtTWIxS1ghxxWfEFGKJ22rvd1IiQ1VKOjUBGh4oq7DZLlFz8T0shMlPSf0t6VVN GwiD7Pb0MHtrhe4Scbzl7RxiUq5gxjduvDMz2HU7FItly8EO1oTcHLJZkQRn4REW c91iqABDpVB9Ktfx/VRNiNTAtCLrSuugfEuj5royJuCRT6ulBOIFwrEb+oQTxmtu /XAu4A2C291RwDjZm2fXi0nzKJ/hHajMZl9P29zAglGbDVe+AmMUCN7HgHe9WQ9+ iOMJ5yDrBPqAVOLpUNdmi+r3Fco6sfIOZhw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1693528154; x=1693614554; bh=dig2Nah7S0wFxy5vubRv0w4mJnfnNG420O3 OX8npovo=; b=B7PENblKIx9fskoRksDFjTxO7PhczwOK1sfxwtAkb+dh61LLVc3 tbJh3sB4vI851NnSB0HU9UsFPqM6EmDn4ZlyR+HubKI3hD6ukPZvQSLnCUfTVrsc l77LheunBreXJsgd+mim/zeYhVdzL7uavvI4VmAKoQVAWRLaThFm/Z/cMLESE+Qm 3hxHWfBLNYvrz9aGOP0/w/wJ+DNrILuooPsG3MqL+Aa6c6c2JoRdalQg9JYDDh7x Wnu/9pMqJ44QYUK/pda+ZpaRXqtNYqU/MXRJqJTLznoWqSo9nuXutnKKzr1KZztK GTD8g8qtjC4XBCSrOrdWCjN2MES7hYLaDag== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudeguddgfeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepiefgteevheevveffheeltdeukeeiieekueefgedugfefgefhudelgfefveel vdevnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 31 Aug 2023 20:29:12 -0400 (EDT) Content-Language: en-US In-Reply-To: <83ttsfel30.fsf@gnu.org> Received-SPF: pass client-ip=64.147.123.24; envelope-from=dmitry@gutov.dev; helo=wout1-smtp.messagingengine.com X-Spam_score_int: -62 X-Spam_score: -6.3 X-Spam_bar: ------ X-Spam_report: (-6.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-3.478, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:309704 Archived-At: On 31/08/2023 10:18, Eli Zaretskii wrote: >> 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. Sounds good. Modification of issues via email is definitely supported to an extent, and some features could be added if missing. >>> 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. As a very low-tech fallback, we would still have emacs-devel, or a separate mailing list where we could forward bug emails from users who don't want to register an account. > 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. I've never worked on any email-related software, and this does sound like a job for a mailing list program. It could be useful to bring in someone with that expertise, even if they only share some ideas about all that. >>>> 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?? I meant tool-assisted code review. As an industry term for a (usually web-based) solution that allows attaching comments to parts of diffs (with an inline view), continuing those discussions, marking comments as "solved", automatic marking of them as "stale" on pushes, and so on. View a separate list of all commits on a branch, commit since last viewer, a combined diff of all commits, and etc. One characteristic of such interfaces is a button called "Merge pull request". Though there are more complex tools, e.g. IIUC Differential (another tool) works with more bureaucracy than that. Of course we can read patches an comment on them without any such tools. Both Debbugs and Bugzilla aren't going to prevent 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? We've known and discussed many of them over the course of a number of years. There is no active development for Debbugs that I know of, and adding all (or most, or any) of those features would really amount to writing a new issue tracker from scratch, which is not really our specialization. It doesn't sound like the best use of our time. Even with "mumi" (Guix's Debbugs replacement that Michael has linked to) I hesitate to discuss any plans of extension because every new web-only or web-oriented, or "modern tracker"-oriented feature would not only be a significant job on its own, it would also be a political fight at the same time, one after another. And, well, I'm not a Scheme hacker anyway, although we know some. By choosing any of the existing bug trackers we would adopt a set of existing well-understood tradeoffs wholesale, which everybody would have to adapt to over time. And then either adjust their workflows or build improvements/additional tools gradually on top of that fixed base. >> 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". The "minimum blood" would be mumi because from what it seems like it retains all the email interactions and adds some moderately better looks when viewed on the web on top of that. As well as faster search. But since it has the least "familiarity" factor among all of the discussed solutions (and features, of course, and usability testing, and etc...), the ability to attract more and more diverse users and developers though modern tooling would correspondingly be lower. There is a sweet spot somewhere, but I don't have any scientific argument for its position. Though if I try to imagine myself 10-15 years younger (rather difficult), the grading would most likely be Github > Gitlab >> Bugzilla > mumi >> Debbugs. Add a pound of salt, of course. There should also be SourceHut on this scale, but I don't know where to put it.