LoginSignup
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

@hon_no_mushi

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

Posted at

Everything you ever wanted to know about Linux -stable releases

For all other submissions, choose one of the following procedures

他すべてのsubmissionsについては、下記手順のいずれかを選択してください。

Option 1

To have the patch automatically included in the stable tree, add the tag Cc: stable at vger.kernel.org in the sign-off area.

stable treeに自動的にパッチを含めるためには、sign-off areaに対して、tagにCc: stable at vger.kernel.org を追加してください。

Once the patch is merged it will be applied to the stable tree without anything else needing to be done by the author or subsystem maintainer.

一度patchがマージされたら、authorやsubsystem maintainerが何をする必要もなく、stabke treeに対しても適用されます。

Option 2

After the patch has been merged to Linus’tree, send an email to stable at vger.kernel.org containing the subject of the patch, the commit ID, why you think it should be applied, and what kernel version you wish it to be applied to.

patchがLinus's treeにマージされた後、 stable at vger.kernel.orgに、patchのsubject, commit ID, なぜそれを適用するべきと考えたのか、このkernel versionに適用するべきかを記載して、メールしてください。

Option 3

Send the patch, after verifying that it follows the above rules, to stable at vger.kernel.org. You must note the upstream commit ID in the changelog of your submission, as well as the kernel version you wish it to be applied to.

上記のルールに従っていることことを確認したら、patchをstable at vget.kernel.orgに送信してください。修正に対するchangelogのupstream commit ID、どのkernel versionに適用しようとしているかを、確実に記載してください。

Option 1 is strongly preferred, is the easiest and most common. Option 2 and Option 3 are more useful if the patch isn’t deemed worthy at the time it is applied to a public git tree (for instance, because it deserves more regression testing first). Option 3 is especially useful if the patch needs some special handling to apply to an older kernel (e.g., if API’s have changed in the meantime).

Option 1は強く推奨されます。これは最も簡単で、最も一般的です。Option 2とOption 3は、patchがpublic git treeに適用されたときに無価値と見なされる場合に、より有効です（例えば、最初により多くのregression testに値するため）。Option 3は特に、patchが多くの特別なハンドリングを古いカーネルに必要になる場合に有効です（例えば、APIが変更されてしまった場合）。

Note that for Option 3, if the patch deviates from the original upstream patch (for example because it had to be backported) this must be very clearly documented and justified in the patch description.

Option 3では、patchがoriginal upstream patchから逸脱している場合（例えば、backportされた場合）、これをpatch descriptionの中で、明快な文書化と、正当化がされている必要があります。

The upstream commit ID must be specified with a separate line above the commit text, like this:

upstream commit IDは、commit textにおいて分離された行で記述されてなければならない。例えば::

commit <sha1> upstream.

Additionally, some patches submitted via Option 1 may have additional patch prerequisites which can be cherry-picked. This can be specified in the following format in the sign-off area:

更に、Option 1で送信されたいくつかのpatchは、cherry-pickedされた事前に必要となる、追加のパッチを有していることもある。signed-off areaに記載する記述は以下になります。

Cc: <stable at vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
Cc: <stable at vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
Cc: <stable at vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
Cc: <stable at vger.kernel.org> # 3.3.x
Signed-off-by: Ingo Molnar <mingo at elte.hu>

The tag sequence has the meaning of:

tag sequenceは、以下の意味を持ちます。

git cherry-pick a1f84a3
git cherry-pick 1b9508f
git cherry-pick fd21073
git cherry-pick <this commit>

Also, some patches may have kernel version prerequisites. This can be specified in the following format in the sign-off area:

更に、いくつかのパッチではkernel versionが事前要求されます。この場合、sign-off areaには以下の記述をしてください。

Cc: <stable at vger.kernel.org> # 3.3.x

The tag has the meaning of:

このタグの意味は以下です。

git cherry-pick <this commit>

For each “-stable” tree starting with the specified version.

指定されたバージョン以降の、それぞれの"-stable" tree。

Following the submission:

  • The sender will receive an ACK when the patch has been accepted into the queue, or a NAK if the patch is rejected. This response might take a few days, according to the developer’s schedules.

  • If accepted, the patch will be added to the -stable queue, for review by other developers and by the relevant subsystem maintainer.

  • 送信者は,patchがqueueに取り込まれたらACKを、patchがrejectされたらNAKを受信します。この反応には、開発者のスケジュール次第ですが、数日を要します。

  • もし取り込まれた場合には、patchは-stable queueに追加され、他の開発者や関連するsubsytem maintainerによって、reviewされます。

Review cycle

  • When the -stable maintainers decide for a review cycle, the patches will be sent to the review committee, and the maintainer of the affected area of the patch (unless the submitter is the maintainer of the area) and CC: to the linux-kernel mailing list.

  • The review committee has 48 hours in which to ACK or NAK the patch.

  • If the patch is rejected by a member of the committee, or linux-kernel members object to the patch, bringing up issues that the maintainers and members did not realize, the patch will be dropped from the queue.

  • -stable maintainersがreview cycleと判断したら、patchはreview comitteeと、パッチに関連する領域のmaintainer(たとえsubmitterが領域のmaintainerだとしても）と、CCにlinux-kernel mailing listを付けて、送信されます。

  • もしパッチがpatchに関連するcomitteeやlinux kernel membersによってリジェクトされたら、maintainersとmemberが認識していない問題が生じた場合、patchはqueueが削除されます。

  • At the end of the review cycle, the ACKed patches will be added to the latest -stable release, and a new -stable release will happen.

  • Security patches will be accepted into the -stable tree directly from the security kernel team, and not go through the normal review cycle. Contact the kernel security team for more details on this procedure.

  • review cycleの最終では、ACKed patchesは 最新の -stable releaseに取り込まれ、新しい -stable releaseが発生します。

  • security patchは、security kernel teamから直接 -stable treeに適用されます、通常のrevire cycleは通さずに。この手続きについては、kernel secutity teamに確認してください。

Trees

Review committee

  • This is made up of a number of kernel developers who have volunteered for this task, and a few that haven’t.

これは、このタスクに志願した多数のカーネル開発者と、志願していない少数とで構成されています。

もともと、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

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?