Re: [GIT PULL] MM updates for 7.3-rc1

On Tue, 18 Aug 2026 at 22:07, Andrew Morton <[email protected]> wrote:
>
> I don't enjoy typing up those patch series summaries, so I haven't been
> doing them well.  This time I recruited Gemini to draft many of the
> bullets and then I did a review/edit pass.  I think the result is
> better(?).

So I fixed up some stuff. I suspect you did the same thing last merge
window too, it had a similar feel to it.

And I detest the silly use of present tense prose for bug fixes etc
("Do ABC, fixing X").

Or the unnecessary use of filler words.

Or saying "This 5 patch series".

Things like that should not matter in a merge message.

You say what changed or what was fixed, not "Five patches to doing ABC
fixing XYZ".

If somebody cares about there being five patches, they'd be looking
at the patches themselves. The merge message should be about
higher-level concepts.

(Or - and if people really care about the delineation of patch series
- maybe it should be visible in the *history* with explicit
no-fastforward merges around the individual series)

I didn't do a *lot* of editing, but let's take a entirely random example:

 - The 2 patch series "selftests/damon: fix memcg_path staging handling"
   from Cheng Nie fixes a bug in _damon_sysfs.py for damos_filter
   memcg_path setup, and adds a test case for it in sysfs.py.

and I edited it to state the basics without present tense:

 - "selftests/damon: fix memcg_path staging handling" (Cheng Nie)

   Fix a bug in _damon_sysfs.py for damos_filter memcg_path setup, and
   add a test case for it in sysfs.py.

iow, straight and to the point. Not "Patch X optimizes abc", just "Optimize abc"

But I guess it's a matter of taste. But if you use Gemini, you could
try to tell it to not use filler words, and use imperative mood. Don't
say "So-and-so did X, fixing Y", just state what was done.

             Linus