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
