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: Confused by y-or-n-p Date: Mon, 04 Jan 2021 19:43:46 +0200 Message-ID: <83eej0bnsd.fsf@gnu.org> References: <834kkcr1eo.fsf@gnu.org> <87k0t38g1z.fsf@mail.linkov.net> <83czyvkts6.fsf@gnu.org> <87bleetirr.fsf@mail.linkov.net> <87y2hhri3n.fsf@mail.linkov.net> <83pn2tkfg8.fsf@gnu.org> <871rf7ippu.fsf@mail.linkov.net> <83a6trg6mc.fsf@gnu.org> <87im8f951f.fsf@gnus.org> <83lfdacapo.fsf@gnu.org> <83wnwsbuwp.fsf@gnu.org> <87mtxo4tph.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32356"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, juri@linkov.net, rudalics@gmx.at, stefankangas@gmail.com, larsi@gnus.org, emacs-devel@gnu.org, drew.adams@oracle.com To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jan 04 18:47:49 2021 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 1kwTxN-0008J6-0y for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 18:47:49 +0100 Original-Received: from localhost ([::1]:39570 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwTxM-0004yU-2D for ged-emacs-devel@m.gmane-mx.org; Mon, 04 Jan 2021 12:47:48 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37706) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kwTty-0002e3-F7 for emacs-devel@gnu.org; Mon, 04 Jan 2021 12:44:18 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39948) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kwTtw-0007dR-2v; Mon, 04 Jan 2021 12:44:16 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4461 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kwTtd-00056z-RJ; Mon, 04 Jan 2021 12:43:58 -0500 In-Reply-To: (message from Stefan Monnier on Mon, 04 Jan 2021 12:17:41 -0500) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:262459 Archived-At: > From: Stefan Monnier > Cc: Eli Zaretskii , Stefan Kangas , > rms@gnu.org, juri@linkov.net, rudalics@gmx.at, emacs-devel@gnu.org, > drew.adams@oracle.com > Date: Mon, 04 Jan 2021 12:17:41 -0500 > > [ FWIW, I also think there are changes we should keep enabled only on > `master` *until* they stop being unpopular. I'm specifically > thinking of things like removal of obsolete features. E.g. we could > have features obsolete since Emacs-25 removed from `master` right > now, but with a way to get them back on-demand, and with the > understanding that they will still be present in the Emacs-28 > release. ] AFAIU, this would need a more complicated procedure for cutting a release branch: some commits would need to be reverted on the release branch. How will we keep the record of those commits? And where is the confidence that reverting a commit months after it was pushed will not break Emacs, e.g. because some later commits depend on that? Unless I completely misunderstand what you propose technically, I think this idea is too hard to implement, at least as long as we have only two active branches active at any given time.