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: New Package for NonGNU-ELPA: clojure-ts-mode Date: Sun, 27 Aug 2023 16:09:29 +0300 Message-ID: <83ledwk4xi.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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12145"; 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 Sun Aug 27 15:10:49 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 1qaFXV-0002xF-L8 for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Aug 2023 15:10:49 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qaFWo-0002J1-6d; Sun, 27 Aug 2023 09:10:08 -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 1qaFWi-0002IG-1Y for emacs-devel@gnu.org; Sun, 27 Aug 2023 09:10:00 -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 1qaFWe-00081F-UD; Sun, 27 Aug 2023 09:09:56 -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=5SyVGv0EqQ8A8qyYvwIxpehBOknnE8yfAuu9IUTXYGU=; b=FKdJ8W43kOkw Lq/454efa/maaz4J/rwXjLOw3qjM4n+Tilp19kEgPizw4L8BJYb4c2NrOYKl+eveyivK5M0suJWqA ojJBnlLzWpZ200qHlWP7vmaA559rqJzdYHtVmVKsH58z/rXm37r/8T9rplFPdZ874HaevpGqXsmTQ 2TUpRzUVT+fnKEn/bv07z3yKXQ6vx/6L/5cmhajTmToIbBizhhcHCUx0TG+zAgY0B2Pz5nsECzXNL 4nKLjH1gbk73PnLkaHArMRmsISjv4JpyryiTEU6l6deoKRGi3+I2pVHgQ07kbZ7vXk0xqLDs+vYt4 qlfgPuEKwDc7veHebQjkqg==; In-Reply-To: (message from Dmitry Gutov on Sun, 27 Aug 2023 15:59:23 +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:309330 Archived-At: > Date: Sun, 27 Aug 2023 15:59:23 +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 14:46, Eli Zaretskii wrote: > >> If the cost is taking over entirely and dedicating 7+ hours every day to > >> Emacs (as you said you do), this is obviously a prohibitive barrier. > > > > The real costs will not be known until you actually do it. I hope > > it's not more, but it could well be less, especially if enough people > > come on board. > > Naturally. But I'm already "on board", aren't I? Just in the areas I > know and for the number of hours that I can dedicate now. 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. > > 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. > >> 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. > >> And the cost is not zero, the cost is the people that never set foot > >> in our community. > > > > That cost is largely imaginary, and "never set foot" is an > > exaggeration. The same was said about the switch to Git, for example, > > but the situation hasn't changed much, if the number of active > > maintainers/developers is concerned. It is better, but only slightly > > so. > > I think you're failing to adjust for natural attrition. Maybe. Who will tell? I only know the facts. > And the effect will naturally be smaller when only one difficult part of > the workflow is replaced, while other remain. It's just like with other > performance optimizations. Maybe. We won't know unless we try. > 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. > 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. > > 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?