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... Signed-off-by: Tudor Ambarus tudor.ambarus@linaro.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 "theoretical race condition" issues, unless an explanation of how the race can be exploited is also provided. - It cannot contain any "trivial" fixes in it (spelling changes,
Hi,
Thanks for your patch.
FYI: kernel test robot notices the stable kernel rule is not satisfied.
Rule: 'Cc: stable@vger.kernel.org' or 'commit <sha1> upstream.' Subject: [PATCH] Documentation: stable: Add rule on what kind of patches are accepted Link: https://lore.kernel.org/stable/20221222091658.1975240-1-tudor.ambarus%40lina...
The check is based on https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
On 12/22/22 16:16, 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.
Are there any other examples of problems that can "only" be solved by introducing new features? Or new huge features that are virtually harder to backport?
Hi,
On 22.12.2022 14:56, Bagas Sanjaya wrote:
On 12/22/22 16:16, 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.
Are there any other examples of problems that can "only" be solved by introducing new features? Or new huge features that are virtually harder to backport?
Here's an example: https://lore.kernel.org/linux-kernel/20221222083545.1972489-1-tudor.ambarus@...
On 12/22/22 20:01, Tudor Ambarus wrote:
Are there any other examples of problems that can "only" be solved by introducing new features? Or new huge features that are virtually harder to backport?
Here's an example: https://lore.kernel.org/linux-kernel/20221222083545.1972489-1-tudor.ambarus@...
I have seen that, but is there an answer for the latter question that I have asked before?
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... Signed-off-by: Tudor Ambarus tudor.ambarus@linaro.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.
So thanks for the patch, but I will not accept it.
thanks,
greg k-h
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... Signed-off-by: Tudor Ambarus tudor.ambarus@linaro.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.
So thanks for the patch, but I will not accept it.
Okay, as you prefer.
Cheers, ta
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... Signed-off-by: Tudor Ambarus tudor.ambarus@linaro.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
linux-stable-mirror@lists.linaro.org
-
Bagas Sanjaya -
Greg KH -
kernel test robot -
Tudor Ambarus