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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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.

So thanks for the patch, but I will not accept it.


Okay, as you prefer.

Cheers,
ta



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux