cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

stable_kernel_rules.txt (5161B)


      1NOTE:
      2This is Japanese translated version of "Documentation/process/stable-kernel-rules.rst".
      3This one is maintained by Tsugikazu Shibata <tshibata@ab.jp.nec.com>
      4and JF Project team <www.linux.or.jp/JF>.
      5If you find difference with original file or problem in translation,
      6please contact maintainer of this file or JF project.
      7
      8Please also note that purpose of this file is easier to read for non
      9English natives and do no intended to fork. So, if you have any
     10comment or update of this file, please try to update Original(English)
     11file at first.
     12
     13==================================
     14これは、
     15linux-2.6.29/Documentation/process/stable-kernel-rules.rst
     16の和訳です。
     17
     18翻訳団体: JF プロジェクト < http://www.linux.or.jp/JF/ >
     19翻訳日: 2009/1/14
     20翻訳者: Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
     21校正者: 武井伸光さん、<takei at webmasters dot gr dot jp>
     22         かねこさん (Seiji Kaneko) <skaneko at a2 dot mbn dot or dot jp>
     23         小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp>
     24         野口さん (Kenji Noguchi) <tokyo246 at gmail dot com>
     25         神宮信太郎さん <jin at libjingu dot jp>
     26==================================
     27
     28ずっと知りたかった Linux 2.6 -stable リリースの全て
     29
     30"-stable" ツリーにどのような種類のパッチが受け入れられるか、どのような
     31ものが受け入れられないか、についての規則-
     32
     33 - 明らかに正しく、テストされているものでなければならない。
     34 - 文脈(変更行の前後)を含めて 100 行より大きくてはいけない。
     35 - ただ一個のことだけを修正しているべき。
     36 - 皆を悩ませている本物のバグを修正しなければならない。("これはバグで
     37   あるかもしれないが..." のようなものではない)
     38 - ビルドエラー(CONFIG_BROKENになっているものを除く), oops, ハング、デー
     39   タ破壊、現実のセキュリティ問題、その他 "ああ、これはダメだね"という
     40   ようなものを修正しなければならない。短く言えば、重大な問題。
     41 - 新しい device ID とクオークも受け入れられる。
     42 - どのように競合状態が発生するかの説明も一緒に書かれていない限り、
     43   "理論的には競合状態になる"ようなものは不可。
     44 - いかなる些細な修正も含めることはできない。(スペルの修正、空白のクリー
     45   ンアップなど)
     46 - Documentation/process/submitting-patches.rst の規則に従ったものでなければならない。
     47 - パッチ自体か同等の修正が Linus のツリーに既に存在しなければならない。
     48  Linus のツリーでのコミットID を -stable へのパッチ投稿の際に引用す
     49   ること。
     50
     51-stable ツリーにパッチを送付する手続き-
     52
     53 - 上記の規則に従っているかを確認した後に、stable@vger.kernel.org にパッチ
     54   を送る。
     55 - 送信者はパッチがキューに受け付けられた際には ACK を、却下された場合
     56   には NAK を受け取る。この反応は開発者たちのスケジュールによって、数
     57   日かかる場合がある。
     58 - もし受け取られたら、パッチは他の開発者たちと関連するサブシステムの
     59   メンテナーによるレビューのために -stable キューに追加される。
     60 - パッチに stable@vger.kernel.org のアドレスが付加されているときには、それ
     61   が Linus のツリーに入る時に自動的に stable チームに email される。
     62 - セキュリティパッチはこのエイリアス (stable@vger.kernel.org) に送られるべ
     63   きではなく、代わりに security@kernel.org のアドレスに送られる。
     64
     65レビューサイクル-
     66
     67 - -stable メンテナがレビューサイクルを決めるとき、パッチはレビュー委
     68   員会とパッチが影響する領域のメンテナ(提供者がその領域のメンテナで無
     69   い限り)に送られ、linux-kernel メーリングリストにCCされる。
     70 - レビュー委員会は 48時間の間に ACK か NAK を出す。
     71 - もしパッチが委員会のメンバから却下されるか、メンテナ達やメンバが気付
     72   かなかった問題が持ちあがり、linux-kernel メンバがパッチに異議を唱え
     73   た場合には、パッチはキューから削除される。
     74 - レビューサイクルの最後に、ACK を受けたパッチは最新の -stable リリー
     75   スに追加され、その後に新しい -stable リリースが行われる。
     76 - セキュリティパッチは、通常のレビューサイクルを通らず、セキュリティ
     77   カーネルチームから直接 -stable ツリーに受け付けられる。
     78   この手続きの詳細については kernel security チームに問い合わせること。
     79
     80レビュー委員会-
     81
     82 - この委員会は、このタスクについて活動する多くのボランティアと、少数の
     83   非ボランティアのカーネル開発者達で構成されている。
     84