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: Choice of bug tracker Date: Mon, 28 Aug 2023 00:15:46 +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> 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="26118"; 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 Sun Aug 27 23:17:01 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 1qaN7z-0006YC-2r for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Aug 2023 23:17:00 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qaN7D-0004sQ-Ar; Sun, 27 Aug 2023 17:16:11 -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 1qaN7C-0004sH-5O for emacs-devel@gnu.org; Sun, 27 Aug 2023 17:16:10 -0400 Original-Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qaN74-0007gz-Hn; Sun, 27 Aug 2023 17:16:09 -0400 Original-Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5F3495C00C6; Sun, 27 Aug 2023 17:15:51 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sun, 27 Aug 2023 17:15:51 -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= 1693170951; x=1693257351; bh=HMx7yqohp4Wmhlnj1axPVY3oq91AL7QrBm0 xqrQS+es=; b=Rf4WDd7qx/bfqrSy3EYFf9W0tYQ+tqSGqbxaOuWmMWQmaocHZEe B3XKzcHW+2NfPaA4ZuWIU6LZ/32l8AqmjGffWKPV+GQ1vJt3rPPYsQGN8MX+sBNJ rGioO0YCtajPs9iXxxcEcZln/xqBAz3fyo7tHAnjny0SnTddjOySC+/cejyGSGnT UsTApgoSlkaEd3wlLprKqlLLsEYyiDVl4lXfyJIMtjx3NkdWv5b5VXY273xsDKNv bnMuXCDtjMcIkIRWDv+XN5RgR+lJ6oz4PfmgYXcoPZwsTcBFm9yC65rTXHGPPx/u eSjMAgWmPomOgNysZ84+CpKJMiiOFSiYxSA== 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= 1693170951; x=1693257351; bh=HMx7yqohp4Wmhlnj1axPVY3oq91AL7QrBm0 xqrQS+es=; b=KHoOetsxWK5a4Jj2Whb5oBo4PSwtadbg5W/NTon+Vs5xKETHecc ULGIwynzSBHvJRxNFsjobdvi6xxkiq3Z5T7sPuBl4jB1/pivG4ZywvHW/OH6NBEM FtxnntHhg+iFqBafPu5Uni9xdpWLT0s7aRYWayldNiclap1+ZJP3m656JffarNhE DXgQCUJg/rFtuDbrwT6B4CE+Eo7MhgJyK/Pewgwb2q63vep+WrIcHTXTaEpn3lMl lvuvdeCtnha2BA+4oe7da77oJenajoYM4+i+MqIAUc9upNrxJG+brScRtqNZD7+a uF836Km0INNa4OizptBLddnhWrmgwadKtpg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudefvddgudeitdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpedtteffudevfefgffffiedtffffudeltdevlefhudfgkefhveeijeeuvdel leekudenucffohhmrghinhepmhhoiihilhhlrgdrohhrghdpfhhrvggvuggvshhkthhoph drohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhm pegumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 27 Aug 2023 17:15:48 -0400 (EDT) Content-Language: en-US In-Reply-To: <83zg2cias7.fsf@gnu.org> Received-SPF: pass client-ip=66.111.4.25; envelope-from=dmitry@gutov.dev; helo=out1-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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:309375 Archived-At: 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. Alas, there are none around. I'm not sure how we could make progress without revisiting said requirements and our priorities. >>> If you do a good job, and the tools are useful, they _will_ be used, >>> and then a buy-in might be a no-brainer. We will see when we get >>> there. >> >> There is no point in me doing either, if the catching issue is how other >> developers find it possible (or not) to work with specific tools. > > Again, I don't understand how or why you arrived to that conclusion. > I don't think it is correct. I might very well be mistaken in my conclusion (happy to be), but it should be easy to see how I arrived at it. >> Should we go through another round of listing bug trackers and voting, >> or something? > > What for? We need tools that satisfy certain requirements, why does > it matter how they are called? If we find a set of tools that can > support our requirements, at least most of the important ones, we > could try using them, and only then it will be known whether the > workflows are good enough and whether the features that are missing > are critical. The phrase "most of the important ones" gives me a bit of hope. > And voting is absolutely the worst method of getting anything > significant done around here. If I used voting for decisions how to > implement bidi, I would still be discussing this on the (now defunct) > emacs-bidi list, instead of having a working implementation. 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. >>>> Important for allowing more people participate in the conversations. >>> >>> That's not the main goal of these tools, as far as the maintainers are >>> considered. >> >> If collecting user feedback and communicating with users is not the main >> goal, and reducing maintainers' workload is the priority, I guess we >> should stop asking for more code to be contributed in Emacs. > > 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. >> 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 >> BTW, if js-ts-mode and others lived in ELPA, there wouldn't be an issue >> of Emacs 29.1 users having ts modes incompatible with the latest >> grammars (they'd just upgrade Elisp code over ELPA). > > Not true. Moving a mode to ELPA doesn't solve that particular problem > (or any other one). But it does. Makes it better, at least. Makes the solution more obvious to the user (I installed it from there -> there is an update -> I'll update it from there now). > On the contrary: having those not bundled would > mean users don't have an OOTB solution, and would need to invent their > own wheels. You can't say "on the contrary" and then go on to state something orthogonal. 'M-x package-install' works, there is nothing to invent. But it would be good if the core leads paid more attention to it and ELPA in general. > 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. > 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 ELPA packages can have their own manuals too, JFYI. > These are the immediate downsides of having a package outside of the > core. > >>>> Perhaps Lisp is denser than JavaScript or C, and et cetera, but it's >>>> hard to argue that Emacs is more complex, or even comparable, to >>>> Firefox. >>> >>> 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. >>>> And if they reached this size in 20 years rather than 40, it's >>>> an evidence to better productivity rather than the opposite, right? >>> >>> They have a Web browser, that's all. >> >> Yeah, a program written in C/C++/Rust which contains an interpreter (and >> multiple jit's) for a dynamic programming language and has most of its >> interface written in it, supports user extensions in the same language, >> support display of arbitrary files and has several related but different >> mechanisms for guiding the visuals and the layout of said display. It >> also supports bidi. > > It's just a browser. All the features you mention are used for Web > browsing. And we're talking on the mailing list for "just a text editor". >>>> According to >>>> https://blog.mozilla.org/en/products/firefox/the-new-firefox-by-the-numbers/ >>>> (article from 2017), >>>> >>>> > 700 authors contributed code to Firefox over ~1 year >>>> >>>> 80 of them were volunteers, "contributors from all over the world". >>>> >>>> and by those 700 authors: >>>> >>>> 75,342 files changed >>>> 4,888,199 lines were added >>>> 6,886,199 lines were changed >>> >>> Counting just "authors" and "contributors" doesn't tell enough, but at >>> least show the comparable numbers for Emacs, okay? >> >> I figured you have said numbers at hand, more or less. But they must be >> lower. > > 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. >> If you like I can try producing them, but what point would you be trying >> to make? > > My point is that Emacs maintenance is a much more complex and > difficult job than the job of those projects. > >> The point I was trying to make that a big and complex project with many >> contributors (bigger than ours, more complex than ours, with more >> developers than here) can be well-served by a workflow that is rather >> different from ours. > > This remains to be shown, because the raw unanalyzed numbers you've > presented don't provide sufficient evidence. I'm not sure what other numbers I could provide, but if you ask specifically, I could try. BTW, another project using gitlab I was thinking of is Mesa. Perhaps reading their moving announcement (from 5 years ago) would be of interest to some: https://lists.freedesktop.org/archives/mesa-dev/2018-May/195634.html There is a subsequent discussion thread as well. 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).