From: Bagas Sanjaya <bagasdotme@gmail.com>
To: Pavel Machek <pavel@denx.de>, Joe Perches <joe@perches.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
torvalds@linux-foundation.org, stable@vger.kernel.org,
lwn@lwn.net, jslaby@suse.cz, Jason Wang <wangborong@cdjrlc.com>
Subject: Re: stable-kernel-rules need updating? Re: Linux 4.14.294
Date: Sun, 25 Sep 2022 08:49:51 +0700 [thread overview]
Message-ID: <d5fb6967-01df-6f64-2f07-718e1becca63@gmail.com> (raw)
In-Reply-To: <20220924182124.GA19210@duo.ucw.cz>
On 9/25/22 01:21, Pavel Machek wrote:
> 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.
>
Seems like these prerequisite trivial patches should have been
Cc: stable, right?
> 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.
Shouldn't kernel test robot catch build failures due to bad patches?
>
> # - 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.
>
As long as these multi-things constitute as one logical change and
requires hundreds of lines, that's OK.
> # - It cannot contain any "trivial" fixes in it (spelling changes,
> # whitespace cleanups, etc).
>
> This is not enforced, nor it can be enforced easily.
But some people had like to see these trivial fixes go through stable tree
(perhaps timing of merging to mainline issues that such fixes miss the
intended merge window).
Thanks.
--
An old man doll... just what I always wanted! - Clara
prev parent reply other threads:[~2022-09-25 1:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-20 10:17 Linux 4.14.294 Greg Kroah-Hartman
2022-09-20 10:17 ` Greg Kroah-Hartman
2022-09-21 18:03 ` Joe Perches
2022-09-22 4:02 ` Bagas Sanjaya
2022-09-22 6:53 ` Greg Kroah-Hartman
2022-09-22 8:26 ` Joe Perches
2022-09-22 8:32 ` Greg Kroah-Hartman
2022-09-22 8:39 ` Joe Perches
2022-09-24 18:21 ` stable-kernel-rules need updating? " Pavel Machek
2022-09-25 1:49 ` Bagas Sanjaya [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d5fb6967-01df-6f64-2f07-718e1becca63@gmail.com \
--to=bagasdotme@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=joe@perches.com \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=lwn@lwn.net \
--cc=pavel@denx.de \
--cc=stable@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=wangborong@cdjrlc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox