From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Emacs release cadence Date: Tue, 29 Aug 2023 02:52:56 +0300 Message-ID: <7859c619-9616-d54f-04a0-adc46982afaa@gutov.dev> 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> <83msybidcs.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22587"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: luangruo@yahoo.com, philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com, emacs-devel@gnu.org, manuel.uberti@inventati.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Aug 29 01:54:20 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 1qam3n-0005ed-4u for ged-emacs-devel@m.gmane-mx.org; Tue, 29 Aug 2023 01:54:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qam2p-0000zg-Lq; Mon, 28 Aug 2023 19:53:19 -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 1qam2m-0000zE-WB for emacs-devel@gnu.org; Mon, 28 Aug 2023 19:53:17 -0400 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qam2h-0000Cq-Bh; Mon, 28 Aug 2023 19:53:14 -0400 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E2F9E5C0182; Mon, 28 Aug 2023 19:53:00 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Mon, 28 Aug 2023 19:53:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1693266780; x=1693353180; bh=UYwOVrDDeQJ0Bn9A4TjzioVzl2Ai6Wj9OCw 2bCuJFl0=; b=WyHOwwl5q8/HPEIzA12z8ZsPbGRAcGs0iir9Py5eqYDyq+orzjz 1JwSnAE0rtrBRMfD3/zQMDRcc2ioiYYx/LuaSsibjKnWJKNgFF03C9XSoaWURu7N H3ChCqRD9uWLcMLJiw4pAIbILBi+al01stZLEsa5d80pTroV/l99iwNe1pJvxGhc wEpTLrVG771NZLHR1ost25cdUUgY6bnK9J/XIbsjLgDNIxcgCJoKYibvzWWYK1/w tx2WrJIpgpBFE5hJzWOpg9cqo4eyWRzkAG4fxXlYiyJTs1fhKgwqta7fJuH6wApg W61S5K/USElMyN805VJ1WEJ78RA5tj5AoFw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1693266780; x=1693353180; bh=UYwOVrDDeQJ0Bn9A4TjzioVzl2Ai6Wj9OCw 2bCuJFl0=; b=qd/q5z703bPRC53Eneu7QpHKBjR2aOvzY0+sTN7ZcJB3Is563Qi POTV5XFHEhPwJ9C4QcdyrXDt4Ied72XSBMLKwa2mrcb12cJIuKOa9V40ItXr0GpI oAxGOoeSom2QyU5xDrGCiXM0BsG6r1gFlPZn+9Yi6rJeoo4hdVjKEfuphnkB430i 6oPhYeAFA5cMTgWXknnZUByEFwEL+Wjmt2QUSGowbP84BlFh6TPUdoptVGYAP2yg 7Yd6GH3qFUXaF9Q8/95yNXR0TmoqIOP7OZzumCa6dpzXntfvrg8sIH0I+HBmYWBO SBEVU07DIvu89FaLAM7q+PzkoTLShDLx2+Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudefhedgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhephfeutdekveeggeetteekfeejffegudduudfhueevleeftdffffeggeeivddv jeelnecuffhomhgrihhnpehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 28 Aug 2023 19:52:58 -0400 (EDT) Content-Language: en-US In-Reply-To: <83msybidcs.fsf@gnu.org> Received-SPF: pass client-ip=66.111.4.29; envelope-from=dmitry@gutov.dev; helo=out5-smtp.messagingengine.com X-Spam_score_int: -49 X-Spam_score: -5.0 X-Spam_bar: ----- X-Spam_report: (-5.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-2.169, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:309462 Archived-At: On 28/08/2023 15:02, Eli Zaretskii wrote: >> 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. Firefox has been releasing patch versions for majorly breaking bugs or 0-day security issues from time to time. Our minor versions carry more changes, but the idea is that we would be releasing more frequently from the main branch (meaning, pushing out new developments). Because of course we could release a hundred minor versions in a month from an already-closed release branch, if we didn't change anything serious inside. >> 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. Looking at the current release history, it took 9 months between the release branch was initially cut and the release. The development time on master preceding that was, depending on how to measure, either ~1 year or 1 year plus however the previous pre-release also took. Anyway, suppose next time we start the release branch only after 6 months. Would you say it will still take 9 months to stabilize? >>>> 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. We cannot really "verify" a fix, just get reasonably confident that it's good. Any time interval we use will increase the confidence, but also at the expense of velocity. And we won't reach 100% confidence still. And velocity is not just about the next shiny thing, it's also about getting fixes to a certain large category of users sooner. >>> 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. It's a simplification to make the explanation shorter. >> 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? No exactly, but I've been around the bug tracker for a little while. > Because I am, and I can tell that (a) we have no > control on how many users will return feedback, But there are factors we could improve (mentioned previously). > 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. Suppose we have a release loop of 6 months (again, a contrived example). Even then we'd have the first month to collect the initial feedback, and then 5 months to act on it (either release a minor version for simple fixes or important regressions, or put it into master and iterate). Further, a shorter release cycle would mean fewer features and less changes in each release (which is both a pro and a con). But less changes also implies fewer potential new bugs to deal with. It's not a linear relation, but a reduction seems logical. >>> 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. If we release the next version of Emacs in 1 year, rather than in 2 years, we'll get some faster feedback anyway from those slow users (even if they take 1-2 months after the release to upgrade and send reports). With those who wait years, we won't get any improvement, of course, but they cannot be helped anyhow. >> 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. There is definitely a cutoff point somewhere when more frequent releases would hurt rather than help: perhaps if it got to a point where the vast majority of our users chose not to upgrade for 2-3 release cycles anyway. But I figure we're not there yet, since the question of shorter development cycles gets brought up with some regularity.