* Re: emacs-29 1ef8b90ae06: Simplify imenu setup for {cmake, dockerfile}-ts-modes
2024-01-27 22:40 ` Stefan Kangas
@ 2024-01-28 1:34 ` Po Lu
2024-01-28 3:00 ` Stefan Kangas
2024-01-28 3:29 ` Dmitry Gutov
2024-01-28 5:57 ` Eli Zaretskii
2 siblings, 1 reply; 11+ messages in thread
From: Po Lu @ 2024-01-28 1:34 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Eli Zaretskii, emacs-devel, dev
Stefan Kangas <stefankangas@gmail.com> writes:
> Po Lu <luangruo@yahoo.com> writes:
>
>> Yes, please. Furthermore, if such bugfix cannot be described as
>> anything but a simplification (with a correspondingly large diff), there
>> should be another approach safer for the release branch.
>
> We must not get overly rigid about that. It takes extra work, and it
> will not always be clear that it's worth the effort. Often it is, but
> sometimes it isn't. We tend to decide on a case-by-case basis.
>
> Furthermore, please keep in mind that Yuan is both the principal author
> and maintainer of our treesitter support. He's closer to the code than
> anyone else, and is thus in the best position to make such judgement
> calls. I see no reason to second-guess him here, myself.
The burden of proof is on the author of the patch, who might be the most
qualified person to comment on tree-sitter, but certainly not imenu,
autoloads, or other areas of Emacs no less affected by this change. The
bug fix in this change should have been separately installed on
emacs-29, with the rest on master.
> If there are any specific technical arguments for why this particular
> change must not be installed on emacs-29, then let's hear them. Neither
> generalizations nor administrative arguments will cut it, I think.
I haven't heard any specific technical arguments as to why this change
is safe. Rather, I'm the person who is frequently told that such
specific statements regarding the safety of a large change are "famous
last words"--which they are, all too often, so I have taken that advice
to heart.
> The above does not necessarily reflect the official line of the project.
??? I was summarizing what I myself have been told and observed over a
certain length of time.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: emacs-29 1ef8b90ae06: Simplify imenu setup for {cmake, dockerfile}-ts-modes
2024-01-28 1:34 ` Po Lu
@ 2024-01-28 3:00 ` Stefan Kangas
2024-01-28 5:21 ` Po Lu
0 siblings, 1 reply; 11+ messages in thread
From: Stefan Kangas @ 2024-01-28 3:00 UTC (permalink / raw)
To: Po Lu; +Cc: Eli Zaretskii, emacs-devel, dev
Po Lu <luangruo@yahoo.com> writes:
> The burden of proof is on the author of the patch, who might be the most
> qualified person to comment on tree-sitter, but certainly not imenu,
> autoloads, or other areas of Emacs no less affected by this change.
? They are not affected by this change though? Are we looking at the
same patch (commit 1ef8b90a)?
Which areas of Emacs do you think are affected? AFAICT, nothing risks
breaking outside of the changed modes. For example, autoloading is not
affected (`declare-function' only affects byte-compilation).
>> If there are any specific technical arguments for why this particular
>> change must not be installed on emacs-29, then let's hear them. Neither
>> generalizations nor administrative arguments will cut it, I think.
>
> I haven't heard any specific technical arguments as to why this change
> is safe.
Did you read Bug#68706? Yuan decided to install it as a bugfix on
emacs-29.
The question is if this change is different from the many other bug
fixes that we routinely install without much justification. This is why
I'm asking for something more specific.
> Rather, I'm the person who is frequently told that such specific
> statements regarding the safety of a large change are "famous last
> words"--which they are, all too often, so I have taken that advice to
> heart.
I don't know which changes this is in reference to, but I know that you
often work on things like X support, that carries with it a bigger risk
for breakage (as it's more complex), and it affects more users to boot.
It is natural to be more careful with changes in core functionality than
in specific modes.
Note also that we have been decided to be more lax when it comes to the
treesitter stuff, seeing as its new in Emacs 29.
>> The above does not necessarily reflect the official line of the project.
>
> ??? I was summarizing what I myself have been told and observed over a
> certain length of time.
Maybe I wasn't clear enough. I didn't entirely agree with the summary,
because it was too rigid to adequately summarize what I understand to
have been our policy so far. What's more, the way it was formulated, I
felt like it was open to the misinterpretation that it reflected some
official decision.
I hope it is more clear now what it is that I wanted to clarify.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: emacs-29 1ef8b90ae06: Simplify imenu setup for {cmake, dockerfile}-ts-modes
2024-01-28 3:00 ` Stefan Kangas
@ 2024-01-28 5:21 ` Po Lu
0 siblings, 0 replies; 11+ messages in thread
From: Po Lu @ 2024-01-28 5:21 UTC (permalink / raw)
To: Stefan Kangas; +Cc: Eli Zaretskii, emacs-devel, dev
Stefan Kangas <stefankangas@gmail.com> writes:
> ? They are not affected by this change though? Are we looking at the
> same patch (commit 1ef8b90a)?
>
> Which areas of Emacs do you think are affected? AFAICT, nothing risks
> breaking outside of the changed modes. For example, autoloading is not
> affected (`declare-function' only affects byte-compilation).
You are correct as to autoloads, but it certainly affects imenu.
> Did you read Bug#68706? Yuan decided to install it as a bugfix on
> emacs-29.
>
> The question is if this change is different from the many other bug
> fixes that we routinely install without much justification. This is why
> I'm asking for something more specific.
Yes I did: it's larger, and encompasses much more than only the fix.
Yuan's precise wording was:
> Thanks Randy, pushed to emacs-29 since it includes a fix.
which does not suggest that the safety of the patch in whole was a
factor in his decision, but only the fact that a bugfix was one
component of the patch. This prompted my reply that the inclusion of a
bugfix is not the sole criterion we expect changes to the release branch
to satisfy, and I trust we are in agreement in this respect.
> I don't know which changes this is in reference to, but I know that you
> often work on things like X support, that carries with it a bigger risk
> for breakage (as it's more complex), and it affects more users to boot.
> It is natural to be more careful with changes in core functionality than
> in specific modes.
>
> Note also that we have been decided to be more lax when it comes to the
> treesitter stuff, seeing as its new in Emacs 29.
No disagreements there, but "the treesitter stuff" doesn't extend to
imenu setup code in major modes which happen to make use of tree-sitter.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: emacs-29 1ef8b90ae06: Simplify imenu setup for {cmake, dockerfile}-ts-modes
2024-01-27 22:40 ` Stefan Kangas
2024-01-28 1:34 ` Po Lu
@ 2024-01-28 3:29 ` Dmitry Gutov
2024-01-28 5:57 ` Eli Zaretskii
2 siblings, 0 replies; 11+ messages in thread
From: Dmitry Gutov @ 2024-01-28 3:29 UTC (permalink / raw)
To: Stefan Kangas, Po Lu, Eli Zaretskii; +Cc: emacs-devel, dev
On 28/01/2024 00:40, Stefan Kangas wrote:
> It is true that we have preferred to avoid bug fixes that might risk
> destabilizing the branch, but this has usually been applied in an ad-hoc
> and not in a rigid fashion. I'm not myself prepared to commit to much
> more rigid guidelines at this point.
We also tend to me more strict when a release is imminent, and less so
otherwise.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: emacs-29 1ef8b90ae06: Simplify imenu setup for {cmake, dockerfile}-ts-modes
2024-01-27 22:40 ` Stefan Kangas
2024-01-28 1:34 ` Po Lu
2024-01-28 3:29 ` Dmitry Gutov
@ 2024-01-28 5:57 ` Eli Zaretskii
2024-01-31 6:44 ` Yuan Fu
2 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2024-01-28 5:57 UTC (permalink / raw)
To: Stefan Kangas; +Cc: luangruo, emacs-devel, dev
> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sat, 27 Jan 2024 14:40:02 -0800
> Cc: emacs-devel@gnu.org, dev@rjt.dev
>
> Po Lu <luangruo@yahoo.com> writes:
>
> > Yes, please. Furthermore, if such bugfix cannot be described as
> > anything but a simplification (with a correspondingly large diff), there
> > should be another approach safer for the release branch.
>
> We must not get overly rigid about that. It takes extra work, and it
> will not always be clear that it's worth the effort. Often it is, but
> sometimes it isn't. We tend to decide on a case-by-case basis.
>
> Furthermore, please keep in mind that Yuan is both the principal author
> and maintainer of our treesitter support. He's closer to the code than
> anyone else, and is thus in the best position to make such judgement
> calls. I see no reason to second-guess him here, myself.
>
> If there are any specific technical arguments for why this particular
> change must not be installed on emacs-29, then let's hear them. Neither
> generalizations nor administrative arguments will cut it, I think.
My arguments for not objecting to this change on the release branch:
. the change only affects these two modes
. the modes are new in Emacs 29, so their fixes should preferably be
in Emacs 29 as well
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: emacs-29 1ef8b90ae06: Simplify imenu setup for {cmake, dockerfile}-ts-modes
2024-01-28 5:57 ` Eli Zaretskii
@ 2024-01-31 6:44 ` Yuan Fu
0 siblings, 0 replies; 11+ messages in thread
From: Yuan Fu @ 2024-01-31 6:44 UTC (permalink / raw)
To: Eli Zaretskii
Cc: Stefan Kangas, Po Lu, Ergus via Emacs development discussions.,
dev
Hey sorry, I didn’t see this thread. I did forget to include the bug number, will make sure I do next time.
> On Jan 27, 2024, at 9:57 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> From: Stefan Kangas <stefankangas@gmail.com>
>> Date: Sat, 27 Jan 2024 14:40:02 -0800
>> Cc: emacs-devel@gnu.org, dev@rjt.dev
>>
>> Po Lu <luangruo@yahoo.com> writes:
>>
>>> Yes, please. Furthermore, if such bugfix cannot be described as
>>> anything but a simplification (with a correspondingly large diff), there
>>> should be another approach safer for the release branch.
>>
>> We must not get overly rigid about that. It takes extra work, and it
>> will not always be clear that it's worth the effort. Often it is, but
>> sometimes it isn't. We tend to decide on a case-by-case basis.
>>
>> Furthermore, please keep in mind that Yuan is both the principal author
>> and maintainer of our treesitter support. He's closer to the code than
>> anyone else, and is thus in the best position to make such judgement
>> calls. I see no reason to second-guess him here, myself.
>>
>> If there are any specific technical arguments for why this particular
>> change must not be installed on emacs-29, then let's hear them. Neither
>> generalizations nor administrative arguments will cut it, I think.
>
> My arguments for not objecting to this change on the release branch:
>
> . the change only affects these two modes
> . the modes are new in Emacs 29, so their fixes should preferably be
> in Emacs 29 as well
The fix comes together with the simplification, so you can’t simply pick it out and only apply the fix. It’ll be a rather wasteful use of time and more error-prone. All the code that the patch removed are copy-paste boilerplate, and the code that replaces them delegate most of the work to existing functions. So I don’t think it’ll destabilize emacs-29.
Yuan
^ permalink raw reply [flat|nested] 11+ messages in thread