qemu-trivial
[Top][All Lists]
Advanced

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

Re: [PATCH 0/6] trivial-patches for 2023-07-16


From: Michael Tokarev
Subject: Re: [PATCH 0/6] trivial-patches for 2023-07-16
Date: Mon, 17 Jul 2023 12:49:26 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0

16.07.2023 18:58, Philippe Mathieu-Daudé wrote:
...
Michael Tokarev (5):
   tree-wide spelling fixes in comments and some messages: migration/
   tree-wide spelling fixes in comments and some messages: s390x
   tree-wide spelling fixes in comments and some messages: arm
   tree-wide spelling fixes in comments and some messages: other
     architectures
   tree-wide spelling fixes in comments and some messages: hw/9pfs

FYI patch subject is usually "subsystem: Topic", see
https://www.qemu.org/docs/master/devel/submitting-a-patch.html#write-a-meaningful-commit-message:

   QEMU follows the usual standard for git commit messages: the first
   line (which becomes the email subject line) is “subsystem: single
   line summary of change”.

Yes Philippe, I know. In this case though, it really is "tree-wide". I tried
to group them by subsystem but it doesn't work that well.  Especially having
in mind how many changes there are (about 400 in total).

This particular series is a pull request, not a review request (I just
forgot to add --subject-prefix=PULL when generating this one).  This is
the changes which has been reviewed by at least one person, out of the
other pile. The others are here, for example:

  https://lists.nongnu.org/archive/html/qemu-devel/2023-07/msg03006.html

and see comments by Peter there:

 https://lists.nongnu.org/archive/html/qemu-devel/2023-07/msg03050.html

My plan is to get the reviewed parts applied, and re-send the rest
once again. This is a huge work already to create the changes to
begin with, and to review them as well.

The initial RFC:

 https://lists.nongnu.org/archive/html/qemu-devel/2023-07/msg02841.html

(not really a cosmetics comment, but various developers have mail
  filters written using this pattern).

It's hardly possible to reliable filter by subsystem, because there's
no formal subsystems defined and the "subsystem:" prefix in emails is
really arbitrary.

/mjt



reply via email to

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