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: Thu, 31 Aug 2023 17:46:13 +0300 Message-ID: <83r0njclsa.fsf@gnu.org> References: <87il9kksqz.fsf@dfreeman.email> <87a5udk1co.fsf@posteo.net> <835y51kslv.fsf@gnu.org> <7a82c524-1aa1-e755-e377-673ebb107a44@gutov.dev> <83r0nok8s4.fsf@gnu.org> <87il90znco.fsf@yahoo.com> <1977fbef-307b-bcf4-9448-64f26916dd65@gutov.dev> <87edjozlqq.fsf@yahoo.com> <43ddad10-49dd-1c49-ebfe-51689780b315@gutov.dev> <83jztgk410.fsf@gnu.org> <83edjojx8c.fsf@gnu.org> <8734zzv7vk.fsf@localhost> <83edjjecmx.fsf@gnu.org> <87wmxbtsd4.fsf@localhost> <83bkeneb8j.fsf@gnu.org> <87ledrtqzx.fsf@localhost> <837cpbe5vx.fsf@gnu.org> <87ttsfs6yo.fsf@localhost> <83v8cvcpqx.fsf@gnu.org> <87a5u7s5ii.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4512"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stefankangas@gmail.com, dmitry@gutov.dev, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 31 16:47:31 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 1qbixE-0000ud-AJ for ged-emacs-devel@m.gmane-mx.org; Thu, 31 Aug 2023 16:47:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qbiwM-00058v-2H; Thu, 31 Aug 2023 10:46:34 -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 1qbiwK-00054B-Sk for emacs-devel@gnu.org; Thu, 31 Aug 2023 10:46:33 -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 1qbiwK-0000YA-Db; Thu, 31 Aug 2023 10:46:32 -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=Ph5vUtFeoUf8jCEG7qwTcv5PFSMgH8sELBuWqvD+Drc=; b=XFTkRORAPJkE wrJ6fJudJe9dNGU75UCmaA1qsMbCwz+QmunBCKDoPZWANABkH1OVUJW/VUWkIeuZe+f2KpM/MWJXj jLaowJ137S4TjnKCHLn+Bcnl45u9sUsr/uVFyHT8t3gNklXhw19gZVNZBBnSxOZJOFY+icMuiz2yS 4jHNsJMq4ecT8N3yR2Bpw6E25vFTtDOXtVo4kHCuJ/4+3cYcOd7Xx8ccHEie6oBCQM2Evz3j0y/QF KS+kRLiOFF9l0p2dTgqe7y9cu/oe6pD4WFxyG9ipTaS0hMigfpqYuOBR1m/tjZRmVs6inu+Hr4+y7 sYvRg2kjKAjLF6Tmo5aFfQ==; In-Reply-To: <87a5u7s5ii.fsf@localhost> (message from Ihor Radchenko on Thu, 31 Aug 2023 13:31:01 +0000) 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:309670 Archived-At: > From: Ihor Radchenko > Cc: stefankangas@gmail.com, dmitry@gutov.dev, emacs-devel@gnu.org > Date: Thu, 31 Aug 2023 13:31:01 +0000 > > Eli Zaretskii writes: > > > (I actually don't understand where this discussion is going. Do you > > really believe I'm so ... unwise, after all these years, that I spend > > two full hours of my time on something that can be easily automated? > > really??) > > No. But I was hoping that this very specific case with only bug fixes > might be easier to automate. If no, alas. The routine tasks is not what takes the time and determines the frequency of releases. What I think we need is some kind of analysis or insights into the way we receive feedback about releases and decide when we have "enough" to make another release. For example, it would be useful, I think, to know how the rate of reports about bugs and regressions depends on time since the release. This could also benefit from tracking specific categories of bugs (e.g., regressions) separately. If someone could run such analyses on our bug DB, it might be useful for setting or changing our criteria for a release, which currently are based on gut feelings, more or less.