linux-kernel - Re: [PATCH] Documentation: stable: Add rule on what kind of patches are accepted

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y6SEuYEK/90dJjMe@kroah.com>
Date:   Thu, 22 Dec 2022 17:24:25 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Tudor Ambarus <tudor.ambarus@...aro.org>
Cc:     sashal@...nel.org, corbet@....net, stable@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        joneslee@...gle.com
Subject: Re: [PATCH] Documentation: stable: Add rule on what kind of patches
 are accepted

On Thu, Dec 22, 2022 at 04:20:42PM +0200, Tudor Ambarus wrote:
> 
> 
> On 22.12.2022 15:32, Greg KH wrote:
> > On Thu, Dec 22, 2022 at 11:16:58AM +0200, Tudor Ambarus wrote:
> > > The list of rules on what kind of patches are accepted, and which ones
> > > are not into the “-stable” tree, did not mention anything about new
> > > features and let the reader use its own judgement. One may be under the
> > > impression that new features are not accepted at all, but that's not true:
> > > new features are not accepted unless they fix a reported problem.
> > > Update documentation with missing rule.
> > > 
> > > Link: https://lore.kernel.org/lkml/fc60e8da-1187-ca2b-1aa8-28e01ea2769a@linaro.org/T/#mff820d23793baf637a1b39f5dfbcd9d4d0f0c3a6
> > > Signed-off-by: Tudor Ambarus <tudor.ambarus@...aro.org>
> > > ---
> > >   Documentation/process/stable-kernel-rules.rst | 1 +
> > >   1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
> > > index 2fd8aa593a28..266290fab1d9 100644
> > > --- a/Documentation/process/stable-kernel-rules.rst
> > > +++ b/Documentation/process/stable-kernel-rules.rst
> > > @@ -22,6 +22,7 @@ Rules on what kind of patches are accepted, and which ones are not, into the
> > >      maintainer and include an addendum linking to a bugzilla entry if it
> > >      exists and additional information on the user-visible impact.
> > >    - New device IDs and quirks are also accepted.
> > > + - New features are not accepted unless they fix a reported problem.
> > 
> > No need to call this out, it falls under the "fixes a problem" option,
> > right?
> > 
> > The goal is not to iterate every single option here, that would be
> > crazy.  Let's keep it short and simple, our biggest problem is that
> > people do NOT read this document, not that it does not list these types
> > of corner cases.
> > 
> 
> When I read the document I thought that new features are not accepted
> at all, so I took into consideration making a custom fix for stable.
> But that would have been worse, as it implied forking the stable and
> would have made backporting additional fixes harder. An explicit rule
> like this would have saved me few emails changed and few hours spent on
> looking for an alternative fix. But maybe others find this a
> common sense implied rule and you won't have to be summoned for it
> anymore.

Let's just say that this is the first time in the 18+ years of stable
kernel development that it has come up as a question like this :)

thanks,

greg k-h