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: Emacs release cadence Date: Mon, 28 Aug 2023 15:02:43 +0300 Message-ID: <83msybidcs.fsf@gnu.org> References: <87il9kksqz.fsf@dfreeman.email> <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> <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> <225f2669-f517-a1cc-cc2c-bef240396c03@gutov.dev> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15047"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, 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 Mon Aug 28 14:04:00 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 1qaayN-0003gO-WD for ged-emacs-devel@m.gmane-mx.org; Mon, 28 Aug 2023 14:04:00 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qaaxl-0008LI-57; Mon, 28 Aug 2023 08:03:22 -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 1qaaxd-0008Jm-0f for emacs-devel@gnu.org; Mon, 28 Aug 2023 08:03:13 -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 1qaaxa-0001z3-1Y; Mon, 28 Aug 2023 08:03:10 -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=PVnkj+bCKEPkD0YZMj8pR2eICGU+j+fU9YppsOeYPew=; b=Ek6iVyrPLJS3 sFbVbEdHxA+XtBc1tZTYzf57j72Q7QtGjzDZqlFgBUsOpFND3ig50eD/F2uNRbiCXXq2qqsouI53h y26dQpkrgMAkeV3ZSW4Xb4s2REx/687gxw+ZLGD0ViIntKQ8gP2xQf2PISjQQEmoT6Oyn5CnP+9xl rDHvgv5KstKTLUTPKW8Jj5oQk20331dfHMx5ka3hTc1A+M4x24kA7t2YF7sjzlumqCRQPn1nAcEqB kZsTSCDZkCPNx9eonUugQHn23TZe0PD1o9YRID5uyq/oiJtp4yDpyj5sywb+qyLv4oz1M7CsNzGJ7 GH6hF0Xu7FyhtGGqtYbGLA==; In-Reply-To: <225f2669-f517-a1cc-cc2c-bef240396c03@gutov.dev> (message from Dmitry Gutov on Mon, 28 Aug 2023 00:43:36 +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:309428 Archived-At: > Date: Mon, 28 Aug 2023 00:43:36 +0300 > Cc: luangruo@yahoo.com, philipk@posteo.net, danny@dfreeman.email, > stefankangas@gmail.com, emacs-devel@gnu.org, manuel.uberti@inventati.org > From: Dmitry Gutov > > >> Releasing a new Emacs, say, even 6 month won't suddenly turn it into a > >> crashing mess. > > > > We already do it, or thereabouts. Check out the last part of > > etc/HISTORY. > > What I meant are more frequent major releases, and some more patch > releases between them. And it looks like we're taking ~2 years between > major releases now. Yes, but this started as a comparison with others, in which case the difference between major and minor is not very relevant, since Firefox, for example, doesn't have that distinction. As for the frequency of major releases of Emacs, my experience so far is that we cannot do much better without some drastic changes in the procedures, which would probably require correspondingly drastic changes in the core team and how it works. > Anyway, specific intervals are not that important, it was just an > example: we could increase frequency, and nothing major would break. IME, nope, we cannot, not by a lot, anyway. > >> But we would get more and faster feedback for new features and > >> changes. > > > > Maybe, maybe not. See below. > > I'm pretty sure what I said is self-obvious: when instead of waiting for > somebody to check out our test builds we cut a release, a lot of people > will get it fairly soon, some later, but on the whole we'll get a lot > more feedback, much faster. If we get feedback, but do not verify that the fixes indeed fixed the problems, and didn't cause unintended problems elsewhere (something that happens with alarming frequency around here), these frequent releases become pointless. > > Are you sure this will help? Here's a typical case: > > > > https://lists.gnu.org/archive/html/help-gnu-emacs/2023-08/msg00454.html > > > > This guy just recently upgraded to Emacs 29, and is reporting a > > significant issue only now, a month after Emacs 29.1 was released. > > As our (and others') experience shows, indeed, there is no way to ensure > that all bugs are fixed, all regressions are ironed out, and nobody is > ever unhappy. Is this what you seriously think we are doing -- waiting for all the bugs to be fixed? It is not useful to discuss serious subjects such as this one with such a non-serious attitude. > Some people will wait longer before upgrading and ignore all pretests. I > only know, again, two things we could possibly do: > > - Get releases out earlier (so the "one month since release" day comes > faster). > - Get a lot more users and/or a lot more feedback from the same users. > > The latter is a bet that even if, maybe, user C only uses Emacs > releases, there will be users D and E with similar enough workflows that > do test our snapshot builds and would report the same problems sooner. > > Some problems will remain unreported anyway. Some stay that way for decades. Are you talking from experience with releasing Emacs and collecting the feedback? Because I am, and I can tell that (a) we have no control on how many users will return feedback, and (b) it takes several weeks(!) to get useful feedback with real problems flowing after a release. This basically invalidates the simplistic model you describe above. > > I've seen similar things many times: people upgrade to a new Emacs > > version months, and sometimes years, after that version was released. > > Try to collect feedback for a release quickly given this upgrade > > schedule. > > People who stay silent about their problems will get what their pay for. Problem is: most of them do. People who want the latest ASAP simply track the development branches, and we have their feedback more or less in real time; more frequent releases will not improve the feedback we get from them. > But another upside of a shorter release cycle: even when encountering > late, embarrassing regressions, we would be able to say "it'll be fixed > in the next point-release" and people will know that they won't have to > wait long. Not useful if people upgrade slowly and lazily. Once again, those who upgrade eagerly simply build from Git.