emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Merging native-comp and pgtk


From: Stefan Monnier
Subject: Re: Merging native-comp and pgtk
Date: Sat, 13 Feb 2021 08:24:19 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

>> So now I'm wondering: what do you think should be the criteria for
>> inclusion into `master`?
> In general?

No, I meant specifically (tho it's of course based on a general
principles, but these can change from case to case).

>> 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).

Great, that clarifies part of the plan.  It also means it's that much
more important to merge them soon into `master`.

>> 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.

I'm sure we don't.
I was just drawing general lines that might apply to these two cases, to
clarify what I'm trying to find out.

>> 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.

What is still unclear for me is what it is that's still "missing".


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]