That might be a weak argument. But sometimes I find these "keywords" helpful when scanning through a range of commits (to try and "visually bisect" quickly). E.g., if something in the interpreter failed, it's likely not one of the commits that start with "doc:" or "gui:".
On the other hand, if something changed only when using the vm evaluator, it's more likely that one of the commits starting with "vm:" is the one to inspect.
If "configure" breaks or gives incorrect results, it's likely one of the commits starting with "build:" that might have caused it.
That's assuming that the commits are categorized "correctly".

"libgui" is a separate library. So, categorizing changes for it is pretty clear cut (and maybe could also be filtered by path). For other parts, that might be less obvious.

There might also be developers that have their main focus on only parts of Octave's code base. For those, these keywords could also be useful.
If you prefer to not use these keywords, or use a different set of keywords that's fine with me.

What do you have in mind?

comment #2:

> We are using a couple of "keywords" to indicate what a commit is about, e.g., "build", "maint", or "gui". These "keywords" are terminated by a colon ":". Please consider using a similar pattern in your commit messages. E.g.: "VM: Change something (bug #56789)."
>

Sure can do =)

Thank you very much for your invaluable work on the VM. That is greatly appreciated! 👍

Just some organizational remarks:
Please include the bug number at the end of the first line of the commit message, e.g., "Add a fancy feature (bug #12345)."
That will make it easier to find potential context or the place to report issues with a change.
That could be done by the creator of the patch or the developer that is pushing it to the repository.

We are using a couple of "keywords" to indicate what a commit is about, e.g., "build", "maint", or "gui". These "keywords" are terminated by a colon ":". Please consider using a similar pattern in your commit messages. E.g.: "VM: Change something (bug #56789)."

I made three quite small patches.

octave_32367.patch:
    Makes Octave buildable on Debian 12 32bit.
    time_t* used where the called function expects *long.

octave_32368.patch:
    Fixes some sloppy pointer arithmetic that makes the VM crash.

octave_32369.patch:
    Fixes a GCC compiler warning that triggers on 32 bit systems.

Test suite runs fine with and without the VM. I get 4 fails that seems to be small precision errors on ode15i, sind, ode15s with and without the VM.

"Abs err 1.7764e-15 exceeds tol 1.1102e-15 by 7e-16"