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: Mon, 28 Aug 2023 14:45:43 +0300 Message-ID: <83pm37ie54.fsf@gnu.org> 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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6590"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com, emacs-devel@gnu.org, manuel.uberti@inventati.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 28 13:47:04 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 1qaahz-0001Ud-Mx for ged-emacs-devel@m.gmane-mx.org; Mon, 28 Aug 2023 13:47:03 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qaahD-00027I-GJ; Mon, 28 Aug 2023 07:46:15 -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 1qaah8-00026f-9V for emacs-devel@gnu.org; Mon, 28 Aug 2023 07:46:11 -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 1qaah6-0006YO-Lz; Mon, 28 Aug 2023 07:46:09 -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=Voxj3BYPp2tNpRKu/C7tf0M0HL9vJSYH3Y/WNxOeMSs=; b=pq7Q1GZq8qpE UzYkltCn1mjprU4d1tZjKxk1DJL72TohNLjcmMDuY36HKZfGahFzwj3T1RTFkupGXD6/5hmMYppuV Ym31sxuVavAO0dY1KyU1l4v/VdrC9VrRaFU5QmcP5Ui1R67ynm+v+y5j829Y4+IDnG+X9BlZJCvAG jGEyG3q12csuDVGzZAB96zTBgORi/KV7fMWz3LZMOpH/T35wSSPrdvz0077jwuTYAerHoVXxQaHN6 Thxly6d5jxF7RACfLtbCAUM6dV9wdd8QsAKvpaA8jmfCus6K46XodfT5c7Yso0dzQWK18AN4Mjk1Z 59tlsCdXx++JiyA2L11uzQ==; In-Reply-To: (message from Dmitry Gutov on Mon, 28 Aug 2023 00:15:46 +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:309426 Archived-At: > 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. > Voting would be one of the ways to arrive at those "only important > requirements". It's not so bad because familiarity is helpful as well > (as we're all aware here, all with existing habits and preferences). > > 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. I hope something like this would be possible. > > 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. > >> At least as far as anything that can possibly live in ELPA is > >> concerned (meaning: clojure-ts-mode yes, project.el or xref no). Let > >> the developers use the trackers they are comfortable with, with > >> maximum flexibility. The proverbial "lean core". > > > > I'm not aware that ELPA packages are forced to use debbugs. We accept > > reports about them on debbugs, but don't enforce that, at least AFAIK. > > That's what I was saying: if we encouraged the use of ELPA more, the > issue of our common bug tracker (and whether it's good or not) would be > a little less important. Though probably not There are known issues with moving more stuff to ELPA, and they have been discussed. IME, trying to solve too many non-trivial problems together makes the problem much harder, sometimes insoluble. > > 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. > > 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? > >>> No, it isn't hard. Compare the number of domains whose expertise we > >>> need, that's the important aspect. > >> > >> They would obviously have more. > > > > Yeah, right. > > > > The list of the kinds of domain expertise we need in Emacs was posted > > in the past, most of it is not needed for those other projects. > > For... web browsers? They are known to be some of the most complex > pieces of software around, these days. We are talking here about different expertise domains, not about software complexity. What browser needs to have experts in PL design and implementation, in byte-compilation, in syntax analysis, in dozens of text encodings and in Unicode standards and algorithms in general, in half a dozen GUI toolkits and window-system events on several platforms, in email, file I/O, sub-processes, search and replace algorithms, in support of dozens of different programming and markup languages? How many of them support both GUI and TTY displays with basically the same code? Emacs has all of those and more, and the day-to-day routine maintenance requires us to apply knowledge in most of these domains. > > 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? > 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.