From Fedora Project Wiki

Line 6: Line 6:


[https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Fedora&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=fedora-cvs%3F Bugzilla に保存されている保留リクエストのリスト]。
[https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Fedora&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=fedora-cvs%3F Bugzilla に保存されている保留リクエストのリスト]。
{{admon/note|歴史|現在 [[New_package_process_for_existing_contributors |Fedora パッケージングプロセス]]は Git を使用しますが、SCM フラグ名のインスタンスとして Bugzilla は未だに CVS を参照します。しかし、それは本当に歴史的な理由からです。CVS、Git や SCM やその他の類似ツールが Fedora パッケージングプロセスの利便性向上のために2010年8月に導入されました。より詳細な情報は Fedora wiki の [[Using_Fedora_GIT |Fedora プロジェクトの Git 使用方法]]に記載されています。}}


パッケージ管理者の承認を要求するリクエストはこのページに記載されているように Bugzilla のチケットにある fedora-cvs フラグを通してリクエストした方が良いです。この作業を行うために fedorabugs グループのメンバーになる必要があります。
パッケージ管理者の承認を要求するリクエストはこのページに記載されているように Bugzilla のチケットにある fedora-cvs フラグを通してリクエストした方が良いです。この作業を行うために fedorabugs グループのメンバーになる必要があります。

Revision as of 00:25, 9 August 2010

紹介

Bugzilla に保存されている保留リクエストのリスト

歴史
現在 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
EPEL は Red Hat Enterprise Linux やその互換ディストリビューションで Fedora パッケージをビルドした無料のアドオンリポジトリを提供する Fedora のサブプロジェクトです。
  • 現在、Fedora で使用される有効なブランチ名: f12 f13 f14 el4 el5el6 です。 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 プロジェクトで自動化されるべき中間の手続きです。その手伝いに興味があるならインフラチームと一緒に調べてください。