Everything you ever wanted to know about Linux -stable releases(1/2)

https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html

---

# Everything you ever wanted to know about Linux -stable releases

（Linuxの安定版リリースについて知りたいことすべて）

Rules on what kind of patches are accepted, and which ones are not, into the “-stable” tree:

"-stable" treeに対して、受け入れられるパッチの種類と、受け入れられないもののルールがあります。

> - It must be obviously correct and tested.
> - It cannot be bigger than 100 lines, with context.
> - It must fix only one thing.
> - It must fix a real bug that bothers people (not a, “This could be a problem…” type thing).
> - It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some “oh, that’s not good” issue. In short, something critical.

- 明らかに正しく、またテストがされている必要があります。
- 多くとも100行は越えない、contextも含めても。
- たった１つのことを解決してください。
- 人々を悩ませている実際のバグを修正しなければなりません（「これは問題になる可能性があります…」という類ではない）
- build error(ただしCONFIG_BROKENがmarkされていないもの）、oops, hang dataの破損、実際のセキュリティ問題、あるいは、"おお、それはよくない"問題を引き起こす問題を解決するもの。要するに、何かしら重要なもの。


> - Serious issues as reported by a user of a distribution kernel may also be considered if they fix a notable performance or interactivity issue. As these fixes are not as obvious and have a higher risk of a subtle regression they should only be submitted by a distribution kernel maintainer and include an addendum linking to a bugzilla entry if it exists and additional information on the user-visible impact.

kernelをdistributionするユーザーにとって報告された重要な問題であって、performanceや対話性に関する問題を解決する場合。これらの修正が、明らかに繊細なregressionの高いリスクを有し、distribution kernelのメンテナナーによってだけ提供され、更に、もしそれが、ユーザーが見えるインパクトに関する追加情報がある場合、bugzilla entryによるリンクを含める必要があります。

> - New device IDs and quirks are also accepted.
- 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, whitespace cleanups, etc).
- It must follow the Documentation/process/submitting-patches.rst rules.
- It or an equivalent fix must already exist in Linus’ tree (upstream).

- 新しいdevice IDとquirks(特徴）を許容するもの。
- 「理論的なレース状態」の問題ではないこと。レースがどのように公開されるのかの説明も提供されていないようなケース。
- "些細な"修正を含めることはできません（スペルの変更、項羽伯のクリーンアップ等）
- Documentation/process/submitting-patches.rstのルールに従う必要があります。
- それまたは同等の修正が、upstreamであるLinus's treeに既に存在している必要があります。

# Procedure for submitting patches to the -stable tree

> - If the patch covers files in net/ or drivers/net please follow netdev stable submission guidelines as described in Documentation/networking/netdev-FAQ.rst after first checking the stable networking queue at https://patchwork.ozlabs.org/bundle/davem/stable/?series=&submitter=&state=*&q=&archive= to ensure the requested patch is not already queued up.
- Security patches should not be handled (solely) by the -stable review process but should follow the procedures in Documentation/admin-guide/security-bugs.rst.

-パッチがnet/ また、drivers/netのファイルの範囲内である場、合、https://patchwork.ozlabs.org/bundle/davem/stable/?series=&submitter=&state=*&q=&archive= におけるstable network queueを最初に確認した後に、Documentation/networking/netdev-FAQ.rst に記載されている、netdev stable submission guidelineを参照して、要求されたパッチがまだqueueに入っていないことを確認してください。
- セキュリティパッチは、-stable revice processsによって（単独で）ハンドリングされません。Documentation/admin-guide/security-bugs.rst.に記述されている手続きを踏む必要であります。

---
もともと、Linux Kernelのソースコードの一部なので、GPLv2扱いになる（はずの認識）。

> https://www.kernel.org/doc/html/latest/index.html
> 
> Licensing documentation
> 
> The following describes the license of the Linux kernel source code (GPLv2), how to properly mark the license of individual files in the source tree, as well as links to the full license text.
> 
> https://www.kernel.org/doc/html/latest/process/license-rules.html#kernel-licensing