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

[Greg KH]

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@xxxxxxxxxx/T/#mff820d23793baf637a1b39f5dfbcd9d4d0f0c3a6
> > > Signed-off-by: Tudor Ambarus <tudor.ambarus@xxxxxxxxxx>
> > > ---
> > >   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