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: Merging native-comp and pgtk Date: Sat, 13 Feb 2021 11:30:39 +0200 Message-ID: <834kige2m8.fsf@gnu.org> References: <07D5E64D-DAD0-45B3-B272-627A73D7CBAE@gmail.com> <87sg6alweo.fsf@gnus.org> <87pn1erewq.fsf@gmail.com> <87wnvlecrw.fsf@gnus.org> <83sg69o3av.fsf@gnu.org> <87mtwhctte.fsf@gnus.org> <459A0475-E3E7-4159-82DF-93809CCF1E24@gmail.com> <87eehng52n.fsf@gnus.org> <87mtwbye5b.fsf@gmail.com> <87czx7ycva.fsf@tcd.ie> <87eehmyalr.fsf@gmail.com> <877dneoewi.fsf@tcd.ie> <875z2yy6z7.fsf@gmail.com> <878s7twq2t.fsf@gmail.com> <84adc238-c424-bb6b-da28-c4232172da5b@gmx.at> <83wnvddtgh.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8108"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Feb 13 10:32:08 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 1lArHb-00020t-TV for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Feb 2021 10:32:07 +0100 Original-Received: from localhost ([::1]:33620 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lArHa-0002l3-U8 for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Feb 2021 04:32:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39584) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lArGT-00025s-8c for emacs-devel@gnu.org; Sat, 13 Feb 2021 04:30:57 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45962) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lArGT-0004Pb-1x; Sat, 13 Feb 2021 04:30:57 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3659 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lArGD-0001Pk-K2; Sat, 13 Feb 2021 04:30:54 -0500 In-Reply-To: (message from Stefan Monnier on Fri, 12 Feb 2021 18:04:10 -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:264586 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Fri, 12 Feb 2021 18:04:10 -0500 > > >> Where are we w.r.t merging those two branches into `master`? > >> IIUC the plan is to include those features as "experimental" in > >> Emacs-28.1, right? If so, I think it's becoming urgent that we merge > >> them into `master`. > > I don't thin it's ready yet, see my other message. > > By "it" you mean both features? No, I meant pgtk. > So now I'm wondering: what do you think should be the criteria for > inclusion into `master`? In general? I'm not sure I want to entertain such a discussion, as it runs a high risk of triggering yet another long dispute. > As written above, I thought the plan was to include those as > experimental features for Emacs-28.1 IMO, it makes little sense having these features as experimental in Emacs 28.1, because that would mean their promotion to mainstream would be delayed till Emacs 29, and that's too far away for such important features. I think we should release them in Emacs 28.1 as fully supported ones. Yes, that could delay Emacs 28.1 a bit, but I think users will want these two features badly enough to justify such a delay (if it indeed happens). > so I thought the criteria were > going to be something like: > - Code is clean enough: doesn't risk introducing regressions into the rest > of the code. > - It's very likely that the feature will reach maturity (i.e. lose > the "experimental" label) in some not too distant future. > - It's already usable enough that most people who're looking forward to > this feature will be fairly satisfied if they try it (it might still > have some rough edges, but by and large it works). I'm not sure we want to codify the criteria, not in general, anyway. We managed to do without any formal criteria until now, including when you were the head maintainer. > > (And why is it urgent? Emacs 27.2 is not out yet, and Emacs 28 is > > supposed to have native-comp included. So we still have quite a long > > way to go.) > > Leaving a feature waiting on a branch for extended period of time > imposes a lot of extra work to keep it up to date (and it can very > discouraging to have to do that if there's no clear set of "things > missing"). I agree with the principle, but its short summary is "as soon as possible", not "urgently". We should, of course, merge each of these branches as soon as they are ready.