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: New Package for NonGNU-ELPA: clojure-ts-mode Date: Sun, 27 Aug 2023 21:13:24 +0300 Message-ID: <76ecf629-a41a-f6e4-f661-2ef926326d6c@gutov.dev> 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> 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="37580"; 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 20:14:16 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 1qaKHA-0009cG-4h for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Aug 2023 20:14:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qaKGa-0003Zz-UX; Sun, 27 Aug 2023 14:13:40 -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 1qaKGV-0003ZS-0p for emacs-devel@gnu.org; Sun, 27 Aug 2023 14:13:35 -0400 Original-Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qaKGR-0001yn-KS; Sun, 27 Aug 2023 14:13:34 -0400 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id C21E75C0053; Sun, 27 Aug 2023 14:13:28 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sun, 27 Aug 2023 14:13:28 -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= 1693160008; x=1693246408; bh=sO+OCykurpeCCStbeLr+wGNyoVFbvN5OtjH b3yGMdQk=; b=ow1+mnauzVNtpkYQ35+BBMNFYNsMw/ssHaWXUyaNCGFc7M4X44T PLKu1b4ukhwwOir7P1xC0dvz8JN5NqbbwOLB1d3MooqUDjzTlYd26hj4mCVY+7lQ ZJfV7xuYMn538KbZyDdJE2tE68FqIfP94oGb6o7lU2wRUtT2YR4OCcP9/6Ca1V+7 V9kmbjARdXfVp19ArHyx+VNuZgj/6TACE0W0iTH8DY3XEbQ/+tNltyAaPrFIEanY 1MB8HWZrz122Of1JhYrTgAv9SzzxEh7iYhOkCXaRkzhJXI1vUMWm3w9WGYTSKbFn GonCFaXD5C7qExNiRhlgkL6Uf9mEqgpC/FQ== 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= 1693160008; x=1693246408; bh=sO+OCykurpeCCStbeLr+wGNyoVFbvN5OtjH b3yGMdQk=; b=SK6i5FcZpuSRtMtNuBtkT12/qrvD0TRUaLB1yNY2GIiDyPJZ5fq yS/Peed1+25zgq3p5RYbIcWtvJ4xdWwUoBo8RzZG7E3YYDHO0ftieQ1wOwuPbci2 RO3koAmiiYABxQALDc54PN9zrvDgxZuo5qqR5gCrNwkie097zintqf2J7rlRbCQs QYk8HShPVcLs73wndmt/kWpNP91VrfPfipGEoa7t33fbYmFfM8pLBKj+VoTOu0e3 c3PinoM9pDNW6RBQHMlYmafpNn3mzgK/OIH6IhpIL+/5AlY07zeSUpFyvjjBvqzA XH6SIiR5D3Z1/Tg1GfBhynN6h7MPD1m96qg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudefvddguddvgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpedttdegtdegffeiveeuieejvdehkeetjeetvedutdfhveejieekleeguedt kefhudenucffohhmrghinheprghllhhiiihomhdrohhrghdpmhhoiihilhhlrgdrohhrgh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhi thhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 27 Aug 2023 14:13:26 -0400 (EDT) Content-Language: en-US In-Reply-To: <83ledwk4xi.fsf@gnu.org> Received-SPF: pass client-ip=66.111.4.27; envelope-from=dmitry@gutov.dev; helo=out3-smtp.messagingengine.com X-Spam_score_int: -31 X-Spam_score: -3.2 X-Spam_bar: --- X-Spam_report: (-3.2 / 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=-0.414, 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:309362 Archived-At: On 27/08/2023 16:09, Eli Zaretskii wrote: > your contributions and efforts are greatly appreciated, but that's not > what I meant. I meant leading the migration process to the > (allegedly) new and better tools, then assessing how well they fit us > and making whatever changes are needed, or concluding they failed the > tests. Thank you, of course. But I'm not sure I could lead anything in this process, given that we can't seem to agree on the basic goals. >>> It is definitely _un_reasonable to suggest/demand such changes when >>> you are doing nothing in practice towards that goal. >> >> What do you want me to do? Set up a standalone Bugzilla installation for >> people to try out? There is an existing demo at >> https://bugzilla-dev.allizom.org/home. >> >> Create a migration script from the Debbugs database to Bugzilla's >> format? > > Some of that, yes. > >> I could probably do that too. But that would result in nothing >> without the leadership's buy-in, just like our Gitlab instance is >> stagnating for a couple of years now. > > 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. Migrating the database isn't going to change that. Should we go through another round of listing bug trackers and voting, or something? >>>> The existing tools "lack important features" to such a degree that it's >>>> not even funny. >>> >>> "Important" for whom? We are doing a reasonable job with them, given >>> the available human resources, don't we? Bugs are triaged, >>> investigated, and most of them fixed; patches are reviewed, commented, >>> and installed. We'd love better tools -- who won't? -- but every tool >>> we examined until now had important gaps. >> >> 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. 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". 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). >> 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. >> 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. >>> What is missing is the number of active developers in each project >>> (which requires a definition of "active developer"), the means and >>> tools they use for issue tracking, and whatever else is relevant. >> >> 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. If you like I can try producing them, but what point would you be trying to make? 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.