Re: Merging native-comp and pgtk

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> 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.