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 15:46:42 +0300 Message-ID: <837cpbe5vx.fsf@gnu.org> References: <87il9kksqz.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> <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> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39932"; 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 14:48:25 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 1qbh60-000A96-QR for ged-emacs-devel@m.gmane-mx.org; Thu, 31 Aug 2023 14:48:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qbh5R-0007By-Fk; Thu, 31 Aug 2023 08:47:50 -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 1qbh53-00078c-44 for emacs-devel@gnu.org; Thu, 31 Aug 2023 08:47:26 -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 1qbh51-00028L-U9; Thu, 31 Aug 2023 08:47:24 -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=mUacWYdVFdDCloIJ4iDZm9/tAWOVZojB3ytdgE7/nHc=; b=aYZSFu9hB1zQ pc874Q0NV3CWKQPPxYVw0NykJsKYbffrCAREyn8Y2DQvy488zS1gSIcmleGidc3zvtMBaTORsaBj5 nrHrBjTpvl+zEfWXDWEzZX66ZpBmmQX37goPwXUZ8EqWpaWTuJ4yfjs4vMfXeGF3qiWZOqN3oNXOa 0Z8QcEVHmPnG/jvQrWw2OoznfI0tKD3wbcQsM3yzI//hyPnDDpGwi8qzoWMg02pXqfSt7dkUyjwEH Fb6RAPNJj57GZzLtmR7b1YGQRp5fup72qBasSGilAr0qp2ti1ZiOzmAessYfb5O2/qb5QBEuUblze WvMOVK1kdksZuFyraaDb8w==; In-Reply-To: <87ledrtqzx.fsf@localhost> (message from Ihor Radchenko on Thu, 31 Aug 2023 11:01:38 +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:309640 Archived-At: > From: Ihor Radchenko > Cc: stefankangas@gmail.com, dmitry@gutov.dev, emacs-devel@gnu.org > Date: Thu, 31 Aug 2023 11:01:38 +0000 > > Eli Zaretskii writes: > > >> For Org, a number of people just update from ELPA. Releasing benefits > >> these users. > > > > I don't see how is that different from updating from Git. > > Not all the users are even familiar with Git. Are you sure? I'm not. And we aren't talking about "all the users", only those who want all the latest fixes ASAP. Emacs is a large and very stable package, so the probability that the latest bugfix affects a particular user is very low. Thus, I believe that people who really need frequent bugfixes are quite a few. > >> So, what about "bugfix" releases? AFAIU, it is mostly producing a > >> release tarball + waiting for Emacs to be packaged on major GNU/Linux > >> distributions. The timing would be anything acceptable for the latter > >> task, which appears to be a bottleneck in such scenario. > > > > That has only disadvantages from my POV: 2 hours of work to produce > > and test a tarball with no benefits at all. If someone wants to > > volunteer to do that, fine. (But then making a tarball by following > > the instructions in make-tarball.txt is easy, and anyone can do that > > for themselves if they want to.) > > Can it be simply automated? Not easily, no. There's always stuff that needs manual intervention. Maybe someone could write and maintain a smart enough program to do that, but it's not trivial, and there are always new issues to add to that.