wiki:maintenance

Version 25 (modified by yasumichi, 12 years ago) (diff)

--

【草稿】リリース済みバージョンのメンテナンス

リリース済みの Vine Linux をサポート、メンテナンスするときの方針を述べます。

サポート期間

パッケージメンテナンスポリシー

処理フロー

具体的な処理フローを書く

Main/Core? Enhancement update の場合

自分が該当 Package のメンテナでない場合は、メンテナ以外が update したい場合の方法に基づき、提案を行う。

  1. Update したい Package とその理由、詳細を(新規)BTS に登録する(提案者)
    • Package 名
    • 対象 Vine Version
    • update したい理由、詳細
    • 参考 URL(あれば)
    • 参考 Vine Linux BTS(あれば)
  1. (新規)BTS、VineSeed ML を活用し、方針を決める
  1. Updated Package を作成する(Package 作成者)
    • Patch のみで対策できた場合は、4. へ
    • Version up により対策を行いたい場合は、承認プロセスを経て、承認を得る
    • 依存関係の変更について
      • 依存関係の追加
        • BuildRequires?:本来ビルド依存であるはずのパッケージがビルド依存漏れである場合は、追加しても構いません。
        • Requires:元々依存していなかったパッケージを追加するのは、原則として禁止とします。必要であれば、新たに BTS へ登録して下さい。
      • 依存関係の削除
        • 報告されているバグフィックスの際に、その時点で依存されているパッケージが不要である、もしくは、間違っているならば、削除して構いません。
  1. Package を incoming へ put する(Package 作成者)
    • put 先の incoming は「VineLinux? incoming」
    • 「proposed-updates」Repository を使い、更新されたパッケージを配布する
      • (参照)リポジトリについて
      • proposed-updates に関する "状態" について  VineSeed:19017
        • まだ手元で作業中 → 割当済み
        • package を put 済み、他 arch ビルド待ち、テスト報告待ち → テスト中
        • 前 arch でテスト報告有り → errata 待ち
  1. (新規)BTS へ Package を put したことを書き込む(Package 作成者)
    • 更新点の案内
    • 互換性に変更ある場合はその情報
    • 関連 URL の情報・関連 Vine Linux BTS
  1. パッケージのテストを行う(全員・元バグ報告者)
    • 「proposed-updates」Repository 経由で package を取得し、install する
    • 元バグ報告者に「proposed-updates」Repository 経由で package を取得できることを伝え、テストしてもらう(「proposed-updates」Repository は公開されている)
    • 正常に install、動作の確認がとれたら、(新規)BTS へその旨書き込む
    • Version up を行った場合は、テスト条件が厳しい
    • 問題が発覚したら 3. へ戻る、問題ないようだったら 7. へ
  1. Packageのリリース(release 権限者)
    • 更新点をもとに アナウンス文書を作成する
    • 「proposed-updates」Repository から「updates」Repository へ package を移動する
    • アナウンス文書を公開する

Main/Core? Security update の場合

自分がメンテナでなくても、メンテナの承認を得ずに作業してよい。 但し、メンテナにその旨連絡するほうがよい。

  1. Security issue を発見したら、Seculity BTS に登録する(発見者)
    • Package 名
    • 対象 Vine Version
    • 詳細
    • 参考 URL
  1. BTS、Security ML を活用し、fix 方針を決める(発見者)
  1. 対策 Package を作成する(Package 作成者)
    • Patch のみで対策できた場合は、4. へ
    • Version up により対策を行いたい場合は、承認プロセスを経て、承認を得る
  1. Package を incoming へ put する(Package 作成者)
    • put 先の incoming は「Security incoming」
    • 「testing」Repository を使い、更新されたパッケージを配布する
  1. Security BTS へ Package を put したことを書き込む(Package 作成者)
    • 更新点の案内
    • 関連 URL の情報
  1. パッケージのテストを行う(Security Team 全員)
    • 「testing」Repository 経由で package を取得し、install する
    • 正常に install、動作の確認がとれたら、Security BTS へその旨書き込む
    • Version up により対策を行った場合は、テスト条件が厳しい
    • 問題が発覚したら 3. へ戻る、問題ないようだったら 7. へ
  1. Packageのリリース(release 権限者)
    • 更新点をもとに アナウンス文書を作成する
    • 「testing」Repository から「updates」Repository へ package を移動する
    • アナウンス文書を公開する

Plus Update の場合

自分が該当 Package のメンテナでない場合、あるいは、 該当 Package が依存されているパッケージのメンテナがすべて自分でない場合は、 メンテナ以外が update したい場合の方法に基づき、 依存されているパッケージのメンテナや ML で相談する。

  1. Package を作成する(Package 作成者)
  1. Package をテストする(Package 作成者)
    • incoming に put する前に、Package 作成者の手元で十分なテストを行う。
      • 自分の環境以外でもテストが必要であれば、ML などでテスト募集を募る。
    • 依存されているパッケージ、依存関係を確認する。
      • vbuilder などを用いて、気付かない間に公式リポジトリにないパッケージが依存していないかの確認する。
  1. Package を incoming へ put する(Package 作成者)
  1. Package を incoming へ put したことを ML で報告する(Package 作成者)
    • 更新点の案内
    • 互換性に変更ある場合はその情報
    • 関連 URL の情報・関連 Vine Linux BTS

Extras Update の場合

plus に従います。

もし継続的にメンテナンスする場合は、plus への昇格を ML で宣言して下さい。

Non-free Update の場合

plus に従います。

self-build 系

  • so name の変更に注意する。