[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
- Re: Merging native-comp and pgtk, (continued)
- Re: Merging native-comp and pgtk, Eli Zaretskii, 2021/02/13
- Re: Merging native-comp and pgtk, Andy Moreton, 2021/02/13
- Re: Merging native-comp and pgtk, Eli Zaretskii, 2021/02/13
- Re: Merging native-comp and pgtk, Andy Moreton, 2021/02/13
- Re: Merging native-comp and pgtk, Eli Zaretskii, 2021/02/13
- Re: Merging native-comp and pgtk, Andrea Corallo, 2021/02/14
- Re: Merging native-comp and pgtk, Andreas Schwab, 2021/02/13
- Re: Merging native-comp and pgtk, Andy Moreton, 2021/02/13
- Re: Merging native-comp and pgtk, Stefan Monnier, 2021/02/12
- Re: Merging native-comp and pgtk, Eli Zaretskii, 2021/02/13
- Re: Merging native-comp and pgtk,
Stefan Monnier <=
- Re: Merging native-comp and pgtk, Eli Zaretskii, 2021/02/13
- Re: Merging native-comp and pgtk, Andrea Corallo, 2021/02/12
- Re: Merging native-comp and pgtk, Eli Zaretskii, 2021/02/13
- Re: Merging native-comp and pgtk, Lars Ingebrigtsen, 2021/02/13
- Re: Merging native-comp and pgtk, Tassilo Horn, 2021/02/13
- Re: Merging native-comp and pgtk, Lars Ingebrigtsen, 2021/02/13
- Re: Merging native-comp and pgtk, Dmitry Gutov, 2021/02/13
- Re: Merging native-comp and pgtk, Lars Ingebrigtsen, 2021/02/13
- Re: Merging native-comp and pgtk, Dmitry Gutov, 2021/02/13
- Re: Merging native-comp and pgtk, Lars Ingebrigtsen, 2021/02/13