Hi!
> @@ -118,7 +118,7 @@ struct report_list { > * @multi_packet_cnt: Count of fragmented packet count > * > * This structure is used to store completion flags and per client data like > - * like report description, number of HID devices etc. > + * report description, number of HID devices etc. > */ > struct ishtp_cl_data { > /* completion flags */
Needless backporting of typo fixes reduces confidence in the backport process.
The upstream commit 94553f8a218540 ("HID: ishtp-hid-clientHID: ishtp-hid-client: Fix comment typo") didn't Cc: stable, but got AUTOSELed [1].
I think we should only AUTOSEL patches that have explicit Cc: stable.
That's not how AUTOSEL works or why it is there at all, sorry.
Perhaps not, but why is AUTOSEL choosing this and why is this being applied without apparent human review?
We always appreciate more review, and welcome it. Sometimes things slip by us as well, like it did for this one. The changelog makes it look like a real fix that is needed.
What part of:
commit 94553f8a218540d676efbf3f7827ed493d1057cf Author: Jason Wang wangborong@cdjrlc.com Date: Thu Aug 4 08:58:14 2022 +0800
HID: ishtp-hid-clientHID: ishtp-hid-client: Fix comment typo
The double `like' is duplicated in the comment, remove one.Signed-off-by: Jason Wang wangborong@cdjrlc.com Signed-off-by: Jiri Kosina jkosina@suse.cz
makes it seem like a candidate for backporting?
Perhaps the eagerness to backport is simply too high.
Eagerness to backport is too high, yes. In this case, I guess "Fix" is what triggered AUTOSEL.
We (as in CIP project) review patches going to stable, and review some at AUTOSEL phase.
OTOH ammount of "too trivial" patches in AUTOSEL and -stable is quite high. I tried to report some, but it did not appear stable team is willing to drop patches just because they are "too trivial".
[Plus there's worse stuff in stable, like known-broken patch being applied then reverted, because that apparently makes it easier for some scripts.]
To make problem worse, sometimes "too trivial" patch is prerequisite for some other patch; but there's no marking making it easy to identify such stuff.
Basically... stable-kernel-rules.rst "needs some updating", or some explanation that people can not expect patches in -stable to follow them.
# Rules on what kind of patches are accepted, and which ones are not, into the # "-stable" tree: # # - It must be obviously correct and tested.
Known-bad patches are applied and reverted.
# - It cannot be bigger than 100 lines, with context.
Way bigger patches are often seen.
# - It must fix only one thing.
If upstream patch fixes 3 things and does 5 cleanups, stable accepts that.
# - It must fix a real bug that bothers people (not a, "This could be a # problem..." type thing).
Patches where changelog says bug is theoretical are often taken. Can get examples if neccessary.
# - It must fix a problem that causes a build error (but not for things # marked CONFIG_BROKEN), an oops, a hang, data corruption, a real # security issue, or some "oh, that's not good" issue. In short, something # critical.
All kind of bugs are fair game. For example, tweaks to remove noise printks.
# - It cannot contain any "trivial" fixes in it (spelling changes, # whitespace cleanups, etc).
This is not enforced, nor it can be enforced easily.
# - It or an equivalent fix must already exist in Linus' tree (upstream).
This is the only real rule for the -stable tree.
Best regards, Pavel