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.bugs Subject: bug#62720: 29.0.60; Not easy at all to upgrade :core packages like Eglot Date: Wed, 19 Apr 2023 19:10:29 +0300 Message-ID: <83zg737szu.fsf@gnu.org> References: <87a5zj2vfo.fsf@gmail.com> <87y1muefks.fsf@gmail.com> <834jpifizy.fsf@gnu.org> <83y1mue1qi.fsf@gnu.org> <83sfd2e01f.fsf@gnu.org> <1a5e5837-513b-84d8-3260-cdbf42b71267@gutov.dev> <83sfcz9rf2.fsf@gnu.org> <09a49ab9-ac72-36a9-3e68-9c633710eba7@gutov.dev> <06d29dbd-0b33-8698-bcb8-c89368612f54@gutov.dev> <252e77fb-9657-a5be-2e86-234f7b05d162@gutov.dev> <83edog84cm.fsf@gnu.org> <8e73ca15-00a3-2082-2dd4-94585a3aa64b@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25472"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62720@debbugs.gnu.org, rpluim@gmail.com, philipk@posteo.net, joaotavora@gmail.com, larsi@gnus.org, monnier@iro.umontreal.ca To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Apr 19 18:11:19 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1ppAOt-0006PV-3p for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 19 Apr 2023 18:11:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ppAOf-00025G-MB; Wed, 19 Apr 2023 12:11:05 -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 1ppAOd-00023L-SW for bug-gnu-emacs@gnu.org; Wed, 19 Apr 2023 12:11:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ppAOc-0001dL-Jh for bug-gnu-emacs@gnu.org; Wed, 19 Apr 2023 12:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ppAOb-0000bT-VM for bug-gnu-emacs@gnu.org; Wed, 19 Apr 2023 12:11:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 19 Apr 2023 16:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62720 X-GNU-PR-Package: emacs Original-Received: via spool by 62720-submit@debbugs.gnu.org id=B62720.16819206312281 (code B ref 62720); Wed, 19 Apr 2023 16:11:01 +0000 Original-Received: (at 62720) by debbugs.gnu.org; 19 Apr 2023 16:10:31 +0000 Original-Received: from localhost ([127.0.0.1]:35627 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ppAO7-0000aj-Bi for submit@debbugs.gnu.org; Wed, 19 Apr 2023 12:10:31 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56934) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ppAO4-0000aN-88 for 62720@debbugs.gnu.org; Wed, 19 Apr 2023 12:10:30 -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 1ppANw-0001Pa-9M; Wed, 19 Apr 2023 12:10:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=mwpCtsMPA3E4FvY1ObQedqRvd2BTGlLQhZUtJXAO17w=; b=KJdO13kKXiBPf2v3F0BU 5vADUxD98GrdPVlpn71cPKzpooB3HA3yvxxt/seTDiwIgk1VOWybjuRvChmY2uI5F5sMpUEmYJg9Q 0tNptVQX9FGKezfPvSW9yZvpjy0XGIQQZFiIy90YCnQLKhUPs/g7aY/dn2Q/ljGFVA+bq5va0ZCty JLfw3rSfpAELRG9zDMbwGRYOxYu6Pv1c8AFYT6B/HniWdpB/gNhBhHHm0mk4DSyAMFE6OoRWPX8KJ rqkKULOJt4VQucAViv/kftVsHrIVUew+Q1w7d489J44Z7inz5cyWzcOPMSpJbp9tI9pl3Gn0LMuES n42B8174d2y0oA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ppANv-0005Fw-FW; Wed, 19 Apr 2023 12:10:19 -0400 In-Reply-To: <8e73ca15-00a3-2082-2dd4-94585a3aa64b@gutov.dev> (message from Dmitry Gutov on Wed, 19 Apr 2023 18:48:00 +0300) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:260278 Archived-At: > Date: Wed, 19 Apr 2023 18:48:00 +0300 > Cc: joaotavora@gmail.com, rpluim@gmail.com, philipk@posteo.net, > 62720@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca > From: Dmitry Gutov > > > And mind you: Emacs 29.1 will not be released tomorrow or the day > > after. We still have at least several weeks till then, with at least > > one more pretest. So the decision whether to import a newer Eglot > > into the release branch doesn't have to be today. However, the > > argument against updating Eglot on the release branch, such as they > > were, are of some vaguely "fundamental" nature, so I'm not sure a few > > more weeks of time will change the decision. No one said something > > like "if Emacs 29.1 were to be released in NN weeks or more, it would > > be okay to update Eglot on the release branch." But then I already > > admitted to not understanding those reasons, so maybe I'm missing > > something here. > > Let's imagine I was making this choice. > > I would include (or propose for inclusion) Eglot 1.x.y in Emacs 29 only > N weeks after it has been tagged on master and thus published to ELPA, > on the condition that no major bugs have been discovered in the meantime > that required major reworks (because any bugfix would reset the timer to > L weeks where L < N, but a major change would reset it to N weeks > again). That would be the general guideline. Add to that the > maintainer's best judgment, who would be able to reduce or extend these > periods on case by case basis as well, according to the changes that > went into every release. > > To answer the original question: N weeks still haven't passed (I guess) > since 1.15 was tagged, so we don't quite know whether it's acceptable > for emacs-29. That is fine with me, assuming N has some reasonable value. It means I could ask you again before the next pretest, and then again before RC, and perhaps you'd then agree to import a newer Eglot. But note that this is not what João is saying. He says 1.14 will not be in Emacs 29.1, period. No matter how long I will drag the pretest. He certainly doesn't want to invest the effort of making Eglot 1.14 less dependent on latest changes in other packages, so as to make sure we could drop Eglot 1.14 into Emacs 29 without risking any problems elsewhere. And that more or less seals the issue, effectively setting your N to infinity.