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@xxxxxxxxxx>
> 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@xxxxxxxxxx>
> Signed-off-by: Jiri Kosina <jkosina@xxxxxxx>
> --------------------------
>
> 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
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Attachment:
signature.asc
Description: PGP signature
