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 19:04:03 +0300 Message-ID: <83bkesjwuk.fsf@gnu.org> References: <87il9kksqz.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> <87il90znco.fsf@yahoo.com> <1977fbef-307b-bcf4-9448-64f26916dd65@gutov.dev> <87edjozlqq.fsf@yahoo.com> <43ddad10-49dd-1c49-ebfe-51689780b315@gutov.dev> <87msyciplu.fsf@posteo.net> <83h6okk3oe.fsf@gnu.org> <87edjoindn.fsf@posteo.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18560"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dmitry@gutov.dev, luangruo@yahoo.com, danny@dfreeman.email, stefankangas@gmail.com, emacs-devel@gnu.org, manuel.uberti@inventati.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 27 18:05: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 1qaIGK-0004ZU-7m for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Aug 2023 18:05:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qaIFe-00065v-VD; Sun, 27 Aug 2023 12:04: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 1qaIFc-000651-Px for emacs-devel@gnu.org; Sun, 27 Aug 2023 12:04:32 -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 1qaIFb-0005VH-6N; Sun, 27 Aug 2023 12:04:31 -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=bZ1wZT+OEeRCtY1IZTQxJ16/RJa8D2bZCVysBxWWbFs=; b=kopLb8dVwp6N RsmW40/WBoDIoxQOj69ceVSMTxzA+dLQsaGkE2paqPFnc0YrhQOkuOlJAx/FZ3L5uVjgLMM2G2hr0 YrVqiNjL0XlzcxsUxzfsmnr3+ikf/1CauNkdy/WIlKKwOvOLna2hEKKhvW2M4/womjofmn0LMvf6s NPnQjaecpDKdn28ffeQqRdN0jEXE7NRxh0KLDUkZxdAYsxAT0J3NXPJGCsOMisY8VYLmKGGVg353B u5HyRZLbRTxW2HOfF0YI/0gwC8H2QUYVJjSWdbN1Hdb7/3BoSVdDTJmrEOIHjIPWAPiUI4zR7/qcB EbuQi8cZoT/yHeDsvIjxqA==; In-Reply-To: <87edjoindn.fsf@posteo.net> (message from Philip Kaludercic on Sun, 27 Aug 2023 14:13:56 +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:309354 Archived-At: > From: Philip Kaludercic > Cc: dmitry@gutov.dev, luangruo@yahoo.com, danny@dfreeman.email, > stefankangas@gmail.com, emacs-devel@gnu.org, > manuel.uberti@inventati.org > Date: Sun, 27 Aug 2023 14:13:56 +0000 > > Eli Zaretskii writes: > > >> From: Philip Kaludercic > >> Cc: Po Lu , Eli Zaretskii , > >> danny@dfreeman.email, stefankangas@gmail.com, emacs-devel@gnu.org, > >> manuel.uberti@inventati.org > >> Date: Sun, 27 Aug 2023 13:25:49 +0000 > >> > >> BTW. what is the current system by which releases are cut? I don't know > >> if the maintainers have a schedule or some general plan for internal > >> usage. > > > > I don't know how to answer this. > > How did you decide when to draw the line between Emacs 29 and Emacs 30? That's when the release branch is cut. But doing so doesn't determine the future release date, except very roughly. When to cut the release branch is up to the maintainers, and IME the reasons are not fixed. The mount of new features and the time since the last major release are important factors, though. > > And why should we take them into account, and not the > > other way around? I have never seen a Debian (or any other distro) > > approach us asking when the next release is expected. > > That is true, but I don't see any reason why there shouldn't be any > cooperation. Neither do I, but cooperation is a two-way street. There's also a problem that we rarely can promise a certain release date, because there are factors out of our control, such as the bugs and regressions reported during pretest, the resources that can dwindle due to "Real Life", etc.