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: Tue, 29 Aug 2023 00:16:09 +0300 Message-ID: References: <87il9kksqz.fsf@dfreeman.email> <87a5uw9ivs.fsf@posteo.net> <87ttt42gna.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> 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="18525"; 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, danny@dfreeman.email, stefankangas@gmail.com, emacs-devel@gnu.org, manuel.uberti@inventati.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 28 23:16:34 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 1qajb6-0004ag-PI for ged-emacs-devel@m.gmane-mx.org; Mon, 28 Aug 2023 23:16:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qajau-000474-Uw; Mon, 28 Aug 2023 17:16:20 -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 1qajas-000469-UO for emacs-devel@gnu.org; Mon, 28 Aug 2023 17:16:18 -0400 Original-Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qajap-0002c6-Ma; Mon, 28 Aug 2023 17:16:18 -0400 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 443F65C00A4; Mon, 28 Aug 2023 17:16:14 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 28 Aug 2023 17:16:14 -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= 1693257374; x=1693343774; bh=CUca7H+3IsyJTZ3FvnP1hJyuQeME5qgd1bB tZk6HHgs=; b=gdnuPv+l+XlTwaXrcayjCY2uB8Trd1oWyupNb4hfoj0wj4j9Cty OM+h5TMmTecY4/xgrMIa1X+6tU5We98K3uHD5y+RAEmtYLqmOhHXjNOuMAihyKKf EffCuhMQXV6gQa8gJj1gEZOcXoQb6IO8+oWg7ysuYAFdpGuwksjt7ORoi9DEiPOW 2wdarQMeuIbGgFS4hhWq54i7JMUyuS73twycnremOUBL+0VmNTOi8R8rPCW/Fldp 3BTpflHneNsbpnS+0gsrQ+qlu+HU6hojuasJw3faULjPrjVgWUo6J8l+CrzH5R7p 3Ik1NHWCWHRBmlzk+HSEkSEGdJjqNfKq4PQ== 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= 1693257374; x=1693343774; bh=CUca7H+3IsyJTZ3FvnP1hJyuQeME5qgd1bB tZk6HHgs=; b=fX7c7Vpzq6QKi3x5D94lR9r7SRkhdZF5NNvSEYWHm0H3D2k/zUB 5d5qOWf4aH1mZok9tGlHUOIkKxi4E4Us+ypfuf/ZXGLpoWIsU+VYaR6skDKOmnm9 IrTISDVb0I15rza2owWO75j84HSc5aNDNOoK3E2GcotG8WBP52Ul3/RQ1MjVa4/x r2ho94pwWkc+2N9hzf7DPrP2xOD+c6gri/o/wyX3F9veUR07wCnEHrLJJkojFXPP IM0J2Dmb4I5UFIEJSMZsY/lKjCMxceOG91vV1dsHv6NlCz0jZ6H/4YoqZnKcKmqV aHDQYWNaljWUx3gXCYnA3EuRgZy5j7DW7ag== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudefgedgudehjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpefhleduhedthfduheevffeuveeileduiefhheefudevveduhffgjeejfeeg veefgeenucffohhmrghinhepghhithhlrggsrdgtohhmnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 28 Aug 2023 17:16:11 -0400 (EDT) Content-Language: en-US In-Reply-To: <83pm37ie54.fsf@gnu.org> Received-SPF: pass client-ip=66.111.4.26; envelope-from=dmitry@gutov.dev; helo=out2-smtp.messagingengine.com X-Spam_score_int: -49 X-Spam_score: -5.0 X-Spam_bar: ----- X-Spam_report: (-5.0 / 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=-2.169, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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:309456 Archived-At: On 28/08/2023 14:45, Eli Zaretskii wrote: >> Date: Mon, 28 Aug 2023 00:15:46 +0300 >> Cc: philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com, >> emacs-devel@gnu.org, manuel.uberti@inventati.org >> From: Dmitry Gutov >> >> On 27/08/2023 21:46, Eli Zaretskii wrote: >> >>> I don't know why you decided we don't agree on the goals. I think we >>> do; >> > the list of requirements for these tools was posted, and AFAIR was >> > agreed upon. >> >> "Agreed upon" maybe in the sense that the leadership sort-of-promised to >> seriously consider a bug tracker which would satisfy the whole list of >> them. > > That's not my position, FWIW. I'm ready to try some less-than-perfect > bug trackers, if the things they lack are relatively minor. > > The problem from my POV was that alternatives were researched, the > results of the research were published and discussed, the downsides > identified, and then the process stalled, perhaps because people got > disappointed by the deficiencies. Last time we produced this overblown list which mixed necessities with nice-to-haves: https://gitlab.com/gitlab-org/gitlab/-/issues/28152 Some of the things there: - ReCaptcha replacement (actually seems fixed now: https://gitlab.com/gitlab-org/gitlab-foss/-/issues/46548#note_203922493) - LibreJS (we already know the JS files have satisfactory licenses; there was a fair amount of discussion around the assets pipeline, but no resolution: https://gitlab.com/gitlab-org/gitlab/-/issues/15196) There were also a few functional things like inability to include diffs in Merge Request notifications which seems like a genuine omission, that seems easy to sell to gitlabbers, and I wouldn't mind looking into. >> Or someone in charge could revisit the list and separate the more >> important requirements from "less important" ones. > > I'd prefer that "someone in charge" took a leap of hope, produced some > site we could use, and let us try it and see how workable is it. If > that/those person(s) did a good job, and would be ready to work on > fixing the issues reported during the initial use until we could make > the final decision, we could have some hope of finding a better tool. > the main challenge in this particular endeavor is that we'd need to > use two different trackers in parallel, at least for some time, so > some solution for syncing them would be in order. Regarding "workability", we have EMBA for people to try out. It's been there for several years. Unless Gitlab is crossed out from the list of contestants already. There is an online demo for Bugzilla. I'm not sure if we need a dedicated one, but if yes, that could also be arranged. >>> Please don't exaggerate and don't consider this a zero-sum game. We >>> want tools that facilitate feedback, but their primary goal is to >>> allow development and maintenance of Emacs. That should be a >>> no-brainer, and I'm frankly astonished this is something that needs to >>> be argued about. What would be the purpose of collecting user >>> feedback and communicating with users if we cannot efficiently apply >>> that to development and maintenance?? >> >> We could apply that information less efficiently, I guess? Though >> whether it's more or less would strongly depend on individual habits. > > The crucial (for me) question is: how much less efficiently? With the > current mail-based flows, reviewing a patch is a snap, and applying a > patch takes mere seconds, even if I need to fix the commit message. > If seconds become minutes, it would be bad for productivity, and > eventually bad for our development rate. I don't see how they become minutes (even browser web pages don't take this long to load), and it's a matter of habit. Anyway, both Gitlab and Bugzilla have means of interacting through email. Any serious omissions can be looked into as well (also see (*)). >>> It also means the instructions about how to install the >>> relevant grammars would not have been in NEWS, so users would need to >>> discover that by themselves. >> >> We could have another NEWS file for ELPA, annotated with timestamps >> and/or Emacs versions as well. A common NEWS feed is easy enough to do >> for the whole ELPA as well. > > There would be no motivation for that. Fact is we don't have such a > file now, and there are good reasons for that. We could also have an entry in Emacs 29's NEWS specifically about the new ts major modes that have just been added to ELPA. Since they wouldn't work with earlier versions of Emacs anyway, that seems appropriate. >>> And the command we added to treesit.el >>> for installing the grammars would be missing as well. Not to mention >>> the documentation in the user manual. >> >> I think treesit.el (since it's inseparable from treesit.c) would still >> be in the core. Along with all its manual entries. > > But the motivation to support unbundled packages would be gone. I' > for example, would not insist on having such a command if it supports > only 3rd-party packages. > >> But ELPA packages can have their own manuals too, JFYI. > > I know. But who monitors their quality and works on improving them? That's the thing: GNU ELPA is supposedly "part of Emacs". So that responsibility is ours, I guess. At least to a certain extent. Currently it's a matter of trusting existing maintainers, which isn't the worst thing to do, too. >>> I'm not sure they will be lower. >> >> Number of lines changed over a year? >> >> The above numbers are 2x and 3x above our total number of lines. And the >> number of changed files is 15x our total. > > They are also much higher than the LOC counts of the respective > packages, so why aren't you surprised in that case? Mozilla's line count is said to be 20M lines, and the changes were counted in 6M changes, 3M deletions over a year. So that checks out. It all depends on the exact counting method, of course (whether each individual diffs' numbers are added, or whether the total diff over a year is used; I'm assuming Mozilla's report is about the latter). >> There seems to be a fair amount of nostalgia there toward Bugzilla, in >> that thread (apparently from people who do like mailing list driven >> workflows for development). > > I don't remember why we rejected Bugzilla (email support, maybe?). I > use it (admittedly, not intensely enough) when I need to report bugs > or submit patches to GDB and Binutils, and find it quite convenient. I suppose it was not in the list of "forges" because it only provides bug tracking. If we don't manage to switch to Gitlab or SourceHut, we can try using Bugzilla, at least. I'm not loving its "new bug" and the nonexistent "most recent issues/activity" pages, but it would still be an improvement. (*) It does support modifying bugs over email. I just yesterday sent a link to the documentation to its "Inbound Email Interface" to Po Lu, which is a Perl script that works on the postfix MTA (maybe other too, IDK) being invoked through .procmail. That discovery actually tells me two things: 1) Many/most email workflows will probably work with Bugzilla, 2) Other bug trackers/forges which have any kind of web API can be adapted in a similar fashion: running a script when an email is received is easier than implementing a new feature in Gitlab, with UI/settings/permissions, so if we find that Gitlab is otherwise okay but its capability to modify issues over email is lacking, I can volunteer to look into this too. The main limitation, however, is that this design requires people to create accounts in the system. Even just to file new reports. We could have a system/bot which would create issues for anonymous users as well, but it's not clear how we would resolve any follow-up questions which usually arise.