紹介
現在 Fedora パッケージングプロセスは Git を使用しますが、SCM フラグ名のインスタンスとして Bugzilla は未だに CVS を参照します。しかし、それは本当に歴史的な理由からです。CVS、Git や SCM やその他の類似ツールが Fedora パッケージングプロセスの利便性向上のために2010年8月に導入されました。より詳細な情報は Fedora wiki の Fedora プロジェクトの Git 使用方法に記載されています。
パッケージ管理者の承認を要求するリクエストはこのページに記載されているように Bugzilla のチケットにある fedora-cvs フラグを通してリクエストした方が良いです。この作業を行うために fedorabugs グループのメンバーになる必要があります。
Bugzilla レポートの fedora-cvs フラグを "?" に変更することは管理者の注意を引く必要があることを意味します。 管理者はあなたの Bugzilla チケットを読んで、あなたのリクエストの世話をしようと試みるでしょう。パッケージ管理のための作業を速く簡単に行うために、あなたのリクエストに対して必要な全ての情報を網羅して標準化された方法で整形するために、このページのガイドラインに従ってください。
リクエストを作成するために、最初に承認されたパッケージを取得するために使用した同じ Bugzilla チケットを必ず使用するように注意してください。
新規パッケージ
あなたのパッケージがパッケージレビュープロセスで承認された後、その承認されたパッケージ向けに作成されるリポジトリのためにリクエストを行う必要があります。レビューを通過した Bugzilla に登録されたあなたのバグのコメントへこのテンプレートをコピーして、fedora-cvs フラグに ? をセットしてください(cvs というフラグ名は純粋に歴史的理由です)。もしあなたが Fedora パッケージグループへ新たに参加したメンバーなら Bugzilla の fedora-cvs フラグをセットするパーミッションを得るために1, 2日待つ必要があるかもしれません。というのは、その同期は1日に1回手動で行われるからです。あなたのリクエストが承諾された後、パーミッションが同期される(10分毎に自動で行われる)のを待ってください。その時点で、あなたのパッケージをチェックアウトすると各 distro ブランチのための空ブランチを含みます。このブランチへあなたのファイルを単純に追加して、コミット、プッシュ、ビルドを行ってください。これらの操作を行うための詳細な情報は Fedora GIT の使用を参照してください。
fx がリリース体制に入るとき、新たに f(X-2) パッケージのリクエストは承認されません。例えば、Fedora14 がリリースされるとき、Fedora 12 の新規パッケージリクエストは承認されません。
New Package SCM Request ======================= Package Name: Short Description: Owners: Branches: InitialCC:
例:
New Package SCM Request ======================= Package Name: pkgname Short Description: summary of package Owners: foo bar Branches: f12 f13 f14 el6 InitialCC: baz
- 現在、Fedora で使用される有効なブランチ名: f16 f17 f18 el5 と el6 です。 devel ブランチは暗黙的に常に作成されるのでリストを必要としません。
- 所有者は1つ又はそれ以上の FAS ユーザ名 を持たなければなりません。あなたが複数の所有者を持つなら、スペースで区切ったリストに2番目の所有者を追加してください。
- InitialCC はこのパッケージに関してメールを受け取る FAS ユーザ名 を含みますが、所有者である必要はありません。1人以上の場合はスペースで区切られてリストされます。
SIG の仮想ユーザ
Bugzilla やコミットメールが CC で指定された関連メーリングリストやグループへ送られて、そういったバグを効率的にリソース配分できるように packagedb にある次の仮想ユーザが InitialCC に使用されます。
| ユーザ名 | メールアドレス |
|---|---|
| anaconda-maint | anaconda-maint-list-redhat.com |
| astronomy-sig | fedora-astronomy-list-redhat.com |
| ctrl-center-team | control-center-maint-fedoraproject.org |
| fonts-sig | fonts-bugs-lists.fedoraproject.org |
| gecko-maint | gecko-maint-redhat.com |
| hams-sig | fedora-hams@fedoraunity.org |
| haskell-sig | fedora-haskell-list-redhat.com |
| i18n-team | i18n-bugs-lists.fedoraproject.org |
| kernel-maint | kernel-maint-redhat.com |
| lvm-team | lvm-team-redhat.com |
| mono-sig | fedora-mono-lists.fedoraproject.org |
| orphan | extras-orphan-fedoraproject.org |
| perl-sig | perl-devel@lists.fedoraproject.org |
| retired | retired-packages-fedoraproject.org |
| virtmaint | fedora-virt-maint@redhat.com |
| xen-maint | xen-maint-redhat.com |
| xgl-maint | xgl-maint-redhat.com |
既存パッケージのパッケージ変更リクエスト
リクエスト:
- 既存パッケージのための追加ブランチ
- その他の特別な git リクエスト、説明を変更する等
リクエストのために、既存のレビューチケットが CLOSED になっている可能性もありますが(reopen しないでください)、そのチケットを使用してください。レビューチケットが存在しない、又はレビューチケットを実際に見つけることができないなら、新しいバグを作成することが認められています。このケースでは、あなたのパッケージ名にコンポーネントを、rawhide にバージョンをセットします。
レビューステータスページへ訪問して、検索ボックスにパッケージ名を入力することでそのレビュー状況を検索することができます。
もしあなたがパッケージの所有者でないなら、新たなブランチを要求する前に最初にパッケージの所有者を確認してください。
大半のケースでは、既存パッケージの所有権と共同メンテナの状況を変更するリクエストを行うためにFedora パッケージデータベースウェブインタフェースを使用することができます。その所有者から応答がない、又はあなたが多くのパッケージに対して多くの変更を行う必要があるとき、代わりに変更を行うために Admin リクエストをオープンすると良いです。
あなたが何をやりたいか、あなたの Bugzilla コメントが正当化される理由を、注意深く正確に記載するために次のテンプレートを使用してください。それから fedora-cvs フラグへ ? をセットしてください。もしそのバグが closed であっても reopen する必要はないことに注意してください。パッケージ管理者は fedora-cvs フラグの状態のみを検索条件としてクエリします。(バグを reopen すると)そのバグが適切に再クローズされるようにオリジナルの解決方法を探す手間暇を管理者に取らせてしまいます。
テンプレート:
Package Change Request ====================== Package Name: New Branches: Owners: InitialCC: [ここに必要な説明内容を追加してください]
Package Name フィールドは必須で、その所有者を表示することが推奨されます。変更又は更新する必要のある他のフィールドのみを含めてください。所有者フィールドはブランチの所有権と共同メンテナを表示します。新たなブランチが作成されるとき、所有権か CC 情報は新たなブランチにコピーされないので、新たなブランチが持っておくべき所有者と初期 CC メンバー全員をそのリクエストで特定する必要があることに注意してください。
EPEL ブランチを追加するためのサンプルです。
Package Change Request ====================== Package Name: pkgname New Branches: el5 el6 Owners: bar foo
その他にテンプレートのフィールドで扱えない特殊な変更を行う必要がある場合、誤った名前で作成されたパッケージは決してビルドされません。もしくはテンプレートの範囲外になります。あなたの Bugzilla コメントに次のテンプレートを使用して要望と正当な理由を説明してください。
アップストリームで名前が変更されたカレントパッケージのために、あなたのリクエストを追加する前に新たなパッケージが作成されてレビューされる必要があります。
これは今後 Infrastructure/PackageDatabase プロジェクトで自動化されるべき中間の手続きです。その手伝いに興味があるならインフラチームと一緒に調べてください。