Package update HOWTO/ja

In other languages: English (en) 中文（中国大陆） (zh-cn) 日本語 (ja) [edit]

This document shows how to submit an update for a package you maintain in Fedora. It assumes you already have a package in the Fedora repositories. It is not a guide to using the Fedora package source control system: see the Package maintenance guide for that.

• For details of the policy on requirements for updates at various stages of the Fedora Release Life Cycle, refer to Updates Policy.

このドキュメントは、Fedoraにおいて保守管理するパッケージの更新を投稿する方法を示したものです。すでにFedoraレポジトリにパッケージを持っていることを前提にしています。Fedoraパッケージソースコード管理システムの使い方ガイドではないです。そちらに関しては、Package maintenance guideをみてください。

• [[Fedora Release Life Cycle]内の色々な段階でパッケージ更新の要求が存在しています。それらの要求に対する原則に関する詳細は、Updates Policyを参照してください。

概要(Overview)

This page is intended for new and existing package maintainers. Testers and regular users may be interested in the updates-testing repository and the update feedback guidelines. This page specifically covers the update submission process.

There are two significantly different package update submission workflows in Fedora:

• Rawhide, and Branched up to the Bodhiが有効になる時点
• Branched releases after the Alpha change deadline, and stable releases

The repository layouts differ somewhat for Rawhide, Branched and stable releases, but the update workflows split up as described above.

このページは、新規及び既存のパッケージ保守管理者を対象としています。テスト担当者及び一般ユーザは、updates-testingレポジトリとupdate feedback guidelinesに興味を持っているかもしれません。このページでは、特にパッケージ更新を投稿する工程について説明します。

Fedoraには、二つの大きなパッケージ更新を投稿する流れがあります。

• Rawhide と Bodhiが有効になる時点までのBranched です。
• Branched リリースは、α版の締め切りのあとのリリースであり、そして、安定版のリリースです。

レポジトリの配置は、Rawhide, Branchedそして、安定版の各リリースで多少異なりますが、更新の流れは、上述のように分割しています。

Rawhideと初期Branched(Rawhide and early Branched)

The package update workflow for Rawhide and Branched before the Bodhiが有効になる時点 is simple:

1. Build the package with fedpkg build (see the Package maintenance guide for more details)

This is all you need to do. Your package will appear in the next daily compose of Rawhide or Branched and will be used in any image composes built from that tree.

RawhideとBodhiが有効になる時点より以前のBranchedにおけるパッケージ更新の流れは単純です。

1. fedpkg buildでパッケージをビルドします。(詳細は、Package maintenance guideを見てください)

あなたがやるべききとはこれだけです。あなたのパッケージは、翌日のRawhideまたはBranchedのcompose（訳注：FedoraOSスナップショット）の中に表示され、そのツリーからビルドされたイメージに使われるようになります。 This is all you need to do. Your package will appear in the next daily compose of Rawhide or Branched and will be used in any image composes built from that tree.

後期ブランチと安定版リリース(Later Branched and stable releases)

At the Bodhiが有効になる時点, the Bodhi update feedback system is enabled by Release Engineering and builds submitted with fedpkg build are no longer automatically sent to any official repository. The update workflow for releases of this type is:

Fedora account name
fedpkg should be able to discover your Fedora account system user name from the ~/.fedora.cert file set up by fedora-packager-setup when you first configured your system for packaging. If this fails for any reason, you can specify it with --user (username). For the bodhi command line tool, you may need to specify your Fedora user name with --user (username) if it differs from your system user name.

1. Build the package with fedpkg build
2. Submit an update for the package with fedpkg update, the Bodhi web interface, or the Bodhi CLI tool. This causes the package to be sent to the updates-testing repository
3. Monitor the update's status and the feedback you receive via the web interface or the emails that are sent to you, and modify it with updated or additional builds if necessary
4. After the update meets the criteria in the Updates Policy and you are satisfied it should be released as a stable update, submit the update to stable with bodhi -R stable or the web interface

Updating inter-dependent packages
If a package you wish to update requires other package(s) to be rebuilt before it or they will work properly, you must submit the builds together as a multi-package update. See below for more details on this.

Bodhiが有効になる時点 とは、 Bodhi パッケージ更新フィードバックシステムが、Release Engineering によって有効にされ、fedpkg build で投稿されたビルドは、これ以降は、公式 repository に対して自動的に送信されません。このときのFedoraのリリースに向けたパッケージ更新の流れは、次の通りです:

Fedora アカウント名
fedpkg は、 Fedora account system のユーザ名を見つけることができます。ユーザ名は ~/.fedora.cert から取得します。このファイルは、 fedora-packager-setup によって、最初にパッケージ作成のためにシステムを設定した時に作成されます。何らかの理由で失敗したら、--user (username)オプションで、ユーザ名を指定できます。bodhi コマンドラインツールに、Fedoraアカウント名を指定する必要があるかもしれません。それはシステムアカウント名が、Fedoraアカウント名と違うときです。-u (username) で指定します。

1. fedpkg buildでパッケージをビルドします。
2. パッケージの更新を投稿するには、fedpkg update もしくは、 Bodhi web interface もしくは、Bodhi CLI toolを使います。これによりパッケージは、updates-testingレポジトリに送信されます。
3. パッケージ更新の状況とWebインターフェースもしくは、メールで受け取ったフィードバックを注視し、必要であれば、更新もしくは追加でビルドして、修正してください。
4. パッケージの更新が、Updates Policy に書かれている基準を満たし、安定したパッケージ更新としてリリースされることに満足した後は、stable レポジトリに更新を投稿してください。 bodhi -R stable もしくは Webインターフェースを使います。

相互依存パッケージの更新
もし更新したいパッケージが、他のパッケージのリビルドを必要としたり、それらのパッケージが正しく動くために必要なのであれば、複数パッケージの更新として、ビルドを投稿しなければなりません。これについての詳細は、belowを見てください。

パッケージ更新における属性情報の更新(Update attributes)

At the time you submit the update, you will be asked for several attributes. The type of the update should be fairly self-explanatory: either it fixes bugs, adds new features, or is a new package.

If you are asked whether you want to send the update to updates-testing or stable, this is a no-op: all updates now go through updates-testing. It does not matter what you choose.

There are several schools of thought on filling out the update description. Some would suggest you consider the target audience: for a stable release, in particular, many Fedora users will see this text, and many of them may not be particularly familiar with your package. Consider not simply describing literally the changes in the update, but explaining as if to an outsider why your are updating the package, what benefits it will bring to them (if any), and anything they may want to note in order to have a smooth update experience.

If you associate one or more bug reports with your update, Bodhi will post comments into Bugzilla to alert those following the bug reports that an update is available. If you mark your update as fixing the bug(s), Bodhi will move the report(s) through the MODIFIED, ON_QA and CLOSED ERRATA states of the bug workflow as your update reaches various points in the process. Using this mechanism can be very useful both for you and for users of your package.

You may set a karma (feedback) level at which the update will automatically be submitted to stable. This is optional. If you choose to use it, please carefully consider an appropriate feedback level. For a relatively obscure package which is quite stable, 1 or 2 may be an appropriate value. For a popular, sensitive and complex package such as firefox or the kernel, the default of 3 may be insufficient and a choice of 5 or even 10 may be appropriate.

更新を投稿する時は、その更新について、いくつかの属性情報を聞かれます。更新タイプは、一目瞭然です: バグ修正、新機能追加、新パッケージのいずれかになります。

更新の送信先を updates-testing レポジトリか stableレポジトリ か聞かれたら、何もする必要はありません: 更新は全部 updates-testing レポジトリを経由します。あなたの選択は重要ではないのです。

更新の説明を記入することに関しては、いくつかの流派（考え方）があります。ある人は、対象となる人を想定すること薦めています: 安定版リリースに関しては、特に、たくさんのFedoraユーザがこのテキストをみるでしょうし、それらの多くは、あなたのパッケージに特別親を覚えないかもしれません。更新の変更点を単に文字通り記述せず、知らない人に相対しているかのように、パッケージを更新している理由、更新する利点、遅滞なく更新するための注意点を説明してください。

パッケージの更新に、一つ以上のバグレポートを関連付ける場合は、Bodhiが、バグジラへのコメントとして、バグレポートの末尾に、更新されたパッケージが利用可能であるという警告を、投稿します。パッケージの更新をバグ修正としてマークすると、Bodhiは、バグレポートの状態を MODIFIED, ON_QA そして CLOSED ERRATAという状態に移動します。この状態は、bug workflow に記載されています。あなたのパッケージ更新は、更新の工程において、いろんなポイントにたどり着きます。この仕組みをつかうことで、あなたにとっても、パッケージの利用者にとっても、とても役に立ちます。

karma (フィードバック) のレベルを設定できます。パッケージ更新は、このkarmaのレベルで、自動的に stableに投稿されます。 これはオプションです。使う選択をすれば、適切なフィードバックのレベルを慎重に熟慮してください。とても安定していることが、比較的知られていないパッケージは、1 または 2が妥当な値となります。有名で、繊細、そして複雑なパッケージ、たとえば、firefox や kernelは、デフォルト値は、 3 では、不十分であり、5 さらには、10 が適当かもしれません。

いつ誰があなたの更新を受理するか?(Who will receive your update, when?)

When a release is in Branched state, the updates-testing repository is enabled by default so most users will see the package, but only packages from the stable fedora repository are used in building milestone releases (Alpha, Beta and Final) and nightly images.

Where a package goes when it is marked as stable differs between Branched and stable releases. In Branched releases, stable packages are pushed to the base fedora repository. In stable releases, stable packages are pushed to the updates repository. However, from the point of view of the packager, this is an insignificant implementation detail. For more details, see Repositories.

When a release is in stable state, the updates-testing repository is disabled by default, but QA team members and others run with it enabled in order to provide testing and Bodhi feedback. The main user population will see your update only when it passes Bodhi, is marked as stable and reaches the updates repository.

リリースが、Branchedの状態のとき、updates-testing レポジトリがデフォルトで有効です。大抵のユーザは、パッケージを見られます。安定版の fedora レポジトリのパッケージは、節目となるリリース（α、β、最終版）と夜間ビルドのイメージをビルドする時に使われています。

パッケージが、安定している と印づけされるとき、パッケージの行き先は、Branched の状態のときと、安定版のリリースの時とで、異なります。Branched リリースの時は、 stable のパッケージは、fedoraレポジトリが基本です。 安定版リリースでは、stable パッケージは、updates レポジトリにプッシュされます。しかしながら、パッケージ保守管理者の視点では、細かい実装は重要ではありません。詳細は、Repositoriesを見てください。

リリースが、安定した状態になると、updates-testing レポジトリは、デフォルトでは無効となりますが、QA チームのメンバーとその他の人は、updates-testing レポジトリを有効にしています。テストとBodhiのフィードバックを提供するためです。主なユーザの人口は、あなたのパッケージ更新が、Bodhiを通過したときに初めて、あなたのパッケージ更新が見えるようになります。それは、安定版としてマークされ、updates レポジトリに到着します。

相互依存パッケージの更新(Updating inter-dependent packages)

If an update you wish to submit would cause a dependency issue of any kind (a strict package dependency error, or simply another package failing to operate correctly) if updated alone, you must not submit the package as a single-package update. You must always collect all inter-dependent or related packages together into a single multi-package update, such that no user will face problems if they install all the packages in the update together.

For example: if you maintain a package libfoo which the package bar depends on, and you need to update libfoo, you should check that bar continues to function correctly with the updated version of libfoo. If it does not, you must ensure the appropriate changes are made to bar, and include the updated bar in your update along with the updated libfoo.

The fedpkg tool does not handle multi-package updates. You can add multiple packages to an update using the Bodhi web application, or the bodhi command line tool. You can pass as many package names as you like to the bodhi --new to create a new multi-package update, or use bodhi --edit to edit an existing update.

It is possible you will run into problems with permissions when trying to add builds of packages you do not have commit privileges for to an update, or trying to add a build for a package you do have privileges for to someone else's update. If you encounter a situation like this, you should contact the release engineering team or a proven packager for help.

You may need a buildroot override to complete a multi-package update successfully. For instance in the case described above, you may need to rebuild bar against the new libfoo package and submit both packages together as a multi-package update. However, in the normal course of events, you would not be able to build another package against your new libfoo build until it reached the stable state. To resolve this dilemma, you can request a buildroot override, which causes the libfoo build to be included in the buildroot for a short time in order to get the bar package build done.

You can request a buildroot override with bodhi: bodhi --buildroot-override=(name-version-release) --duration=2 --notes="Useful details." This would submit a buildroot override with a duration of two days. Buildroot overrides are usually granted within 15-30 minutes of submission. If you submit an override request with the bodhi tool, it will suggest a command that will let you monitor when the package appears in the buildroot, so you can fire your dependent build at the appropriate time.

You can also request buildroot overrides from the Bodhi web application.

The buildroot override instructions explain the buildroot override process in more detail.

投稿しようとしているパッケージ更新が、単独で更新して、依存関係の問題（厳しいパッケージ依存関係によるエラーや、単にもう一つのパッケージが正しく実行できないなど）を引き起こすと、単一のパッケージ更新として、パッケージを投稿してはいけません。全ての相互依存パッケージもしくは、関連するパッケージを一緒にして、一つの複数パッケージ更新にまとめなければなりません。ユーザが全てのパッケージを一度の更新でインストールしようとするならば、だれも問題に直面することがないです。

例: あなたが保守管理している libfoo パッケージは、 bar パッケージが依存しています。libfoo パッケージを更新する必要があるならば、更新された libfoo バージョンと一緒に、 bar が 引き続き正しく機能し続けていることを確認すべきです。もし、正しく機能していないならば、bar に適切な変更が行われていることを確認する必要があります。そして、あなたの更新には、更新された bar パッケージを、更新された libfoo パッケージと一緒に含めなければいけません。

fedpkg ツールは、複数のパッケージ更新を取り扱えません。Bodhi web application もしくは bodhi コマンドラインツールを使って、複数のパッケージを一度の更新に追加できます。bodhi --new に好きな数だけパッケージ名を渡して、複数パッケージの更新を作りるか、bodhi --edit を使って既存の更新を編集してください。

パッケージ更新の時に、あなたがコミット権限を持たないパッケージのビルドを追加しようとすると、権限の問題に直面するかもしれません。もしくは、他人のパッケージ更新に対して、あなたが権限を持っているパッケージのビルドを追加しようとするときも権限の問題に直面する可能性があります。もしそのような事態に遭遇したら、release engineeringチームか、実績あるパッケージ保守管理者に援助を求めて連絡を取るべきです。

複数パッケージ更新を成功させるためには、buildroot overrideが必要かもしれません。例えば、上のようなケースでは、新しい libfoo パッケージに対して、 bar パッケージをリビルドし、両方のパッケージを、一つの複数パッケージの更新として、投稿する必要があります。しかしながら、通常のビルドの流れでは、新しい libfoo ビルドに対して、もう一つのパッケージをビルドできません。libfoo が stable レポジトリに到達するまでは、もう一つのパッケージをビルドできません。このジレンマを解決するために、buildroot override をリクエストします。これは、libfooのビルドに、 少しの間だけ、barパッケージをビルドするためのビルドルートを含めさせます。

bodhiで、buildroot override を要求できます: bodhi --buildroot-override=(name-version-release) --duration=2 --notes="Useful details." これによって、二日間のビルドルートを上書きすることを送信されます。ビルドルートの上書きは、投稿後大抵15-30分間以内に容認されます。もし、 bodhiツールで上書きリクエストを投稿したなら、そのパッケージがビルドルートにあわわれる時にあなたに知らせるように、コマンドを推奨されるので、適当なタイミングで、依存しているビルドを起動できます。

Bodhi web applicationでも、ビルドルートの上書きを要求できます。

buildroot override instructionsでは、詳しくビルドルートの上書きについて説明しています。

自動テストからのフィードバックを処理する(Handling feedback from automated tests)

Fedora's automated testing systems, Taskotron and OpenQA, may run automated tests on your update. Several of the Taskotron/Tasks are documented. The openQA tests are functional tests of some critical Workstation and Server features.

In the Bodhi web interface, updates have a Automated Tests tab which displays the results of all automated tests. Tests shown with a red background failed. The tests are not all 100% accurate, but they are fairly often correct. If you see a failure, it is a very good idea to click on the result (which will take you to a detailed log) and investigate the issue. If you are unsure what the test indicates, you can contact the QA team for help.

Fedoraの自動テストシステムである Taskotron と OpenQAは、パッケージの更新に対して、自動テストを実行するかもしれません。Taskotron/Tasks のいくつかは、ドキュメントになっています。OpenQAのテストは、重要なWorkstation と Server の特徴である機能テストです。

Bodhi の Web インターフェースでは、パッケージの更新には、Automated Tests タブがあります。ここには、全ての自動テストの結果が表示されます。背景が赤のテストは失敗しています。テストは全て100%正確ではないのですが、かなり正しいです。 失敗を見つけたら、結果をクリックし（詳細ログが表示されます）、問題を調べるのはとても良い考えです。テストが示していることに自信が持てない時は、QA チームに助言を求めるために、連絡を取ることもできます。

結果を放棄する(Waive a result)

At present, a failure of the dist.rpmdeplint, dist.abicheck, or org.centos.prod.ci.pipeline.complete tests will prevent your update from being released. On the update's Details page in the Bodhi web interface, the Test Gating Status will be shown as N of N required tests failed. If you are sure such a failure is a false one, you can 'waive' the result using the waiverdb-cli tool, from the waiverdb-cli package (there is work pending to be able to waiver more easily, directly from the Bodhi UI).

You can submit a waiver for a failing result with waiverdb-cli specifying the subject and the testcase:

 waiverdb-cli -t YOUR_TESTCASE_HERE -s '{"item": "this-is-the-subject", "type": "also-this-is-part-of-the-subject"}' -p "fedora-26" -c "This is fine"

Example:

 waiverdb-cli -t dist.rpmdeplint -s '{"item": "python-requests-1.2.3-1.fc26", "type": "koji_build"}' -p "fedora-26" -c "This is fine"

You can also waive a failing result by result's id, which you can retrieve from resultsdb with curl. To do that, you'll need the testcase name and the nvr. For example:

 curl "https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0/results?testcases=dist.python-versions&item=python-alembic-0.9.7-1.fc27" | jq ".data[0].id"

This should print out the result_id of the failing result. You can then submit a waiver for this failing result with waiverdb-cli

 waiverdb-cli -p fedora-27 -r YOUR_ID_HERE -c "This is fine."

Also, if you enabled automatic stable push at a karma threshold, this will be disabled if any automated test fails. If you have examined the result and you are sure it is a false one and there is no problem with the package, you may re-enable the automatic push mechanism or submit the package to stable manually once it meets the other requirements of the Updates Policy.

現時点では、dist.rpmdeplint, dist.abicheck, もしくは org.centos.prod.ci.pipeline.complete の各テストが失敗すると、パッケージの更新をリリースできません。Bodhi Webインターフェースのアップデートの Details ページでは、 Gating Status のところに、 N of N required tests failed　と表示されます。もしそのような失敗が、間違いであると確信できるときは、その結果を '放棄' でいます。それには、waiverdb-cli ツールを使います。このツールは、waiverdb-cliパッケージに含まれています。(work pendingですが、直接 Bodhi UIから、もっと簡単に放棄することができます。).

失敗した結果を放棄するように投稿できます。waiverdb-cli ツールに、 subject と testcaseを指定します:

 waiverdb-cli -t YOUR_TESTCASE_HERE -s '{"item": "this-is-the-subject", "type": "also-this-is-part-of-the-subject"}' -p "fedora-26" -c "This is fine"

例:

 waiverdb-cli -t dist.rpmdeplint -s '{"item": "python-requests-1.2.3-1.fc26", "type": "koji_build"}' -p "fedora-26" -c "This is fine"

テスト結果のIDを使って、失敗しているテスト結果を放棄することもできます。テスト結果のIDは、curlコマンドを使って、resultsdbから取得できます。testcase 名と nvrが必要となります。例:

 curl "https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0/results?testcases=dist.python-versions&item=python-alembic-0.9.7-1.fc27" | jq ".data[0].id"

失敗している結果の result_id が表示されるはずです。そのあと、waiverdb-cli を使って、失敗している結果に対して、放棄することを投稿できます。

 waiverdb-cli -p fedora-27 -r YOUR_ID_HERE -c "This is fine."

また、karmaの閾値になったら、自動的にstableレポジトリにプッシュされるようにしている場合は、自動テストが失敗すると、自動プッシュは無効になります。もし結果を精査して、それが間違いで、パッケージに問題がないと確信したならば、もう一度自動プッシュのメカニズムを有効にするか、手動で、stableレポジトリにパッケージを投稿しても良いです。パッケージが、Updates Policyの他の要求を満たしているならば、です。

存在しない結果を放棄する(Waive the absence of a result)

Submitting a waiver using subject/testcase allows to waive the absence of a result (eg. the test never ran for some reason, so there is no result item).

If which testcase you should be specified it is not clear/known, it is possible to run this python script, chainging it with the corrects parameter:

件名/テストケースを使って、テスト結果を放棄することを投稿すると、テスト結果がないことを放棄できます。(例. テストが何らかの理由で実施されない場合、テスト結果項目はありません)

どのテストケースを指定する必要があるかが明確にわからない場合は、以下のpythonスクリプトを走らせることも可能です。正しいパラメータで、繋げて実行してください。

#!/usr/bin/env python
""" Ask a question of greenwave.  """
# Usage: either modify and set PRODUCT_VERSION and NVR_LIST and run, or pass version as first arg and then NVRs as further args
import pprint
import requests
import sys
PRODUCT_VERSION = 'fedora-27' if len(sys.argv) == 1 else sys.argv[1]
NVR_LIST = [] or sys.argv[2:]  # Insert your NVRs here, or pass them via command line args
for nvr in NVR_LIST:
    url = (
        'https://greenwave-web-greenwave.app.os.fedoraproject.org/'
        'api/v1.0/decision')
    payload = dict(
        #verbose=True,
        decision_context='bodhi_update_push_stable',
        product_version=PRODUCT_VERSION,
        subject=[{'item': nvr, 'type': 'koji_build'}],
    )
    response = requests.post(url, json=payload)
    print("-" * 40)
    print(nvr, response, response.status_code)
    data = response.json()
    print(pprint.pformat(data))

The output will show that Greenwave is requiring a specific testcase to run, but it cannot find a result for it (neither pass nor failure). So now it is possible to submit a waiver with the specified testcase in the output and the subject already known.

Greenwaveは、実行するには、特定のテストケースを必要としていますということを表示するでしょう。しかし、それに対する結果は見つけられません（成功も失敗も）。そのため、出力に指定されたテストケースと既知の件名でテスト結果を放棄することができます。

トラブルの解決方法(Troubleshooting)

waiverdb-cli ツールを実行すると、次のようなエラーが表示されます:

 Error: The config option "resultsdb_api_url" is required

/etc/waiverdb/client.conf に次の行を追加してください:

 resultsdb_api_url=https://taskotron.fedoraproject.org/resultsdb_api/api/v2.0

節目ごとのBranchedの凍結（Branched milestone freezes）

For a short period before each milestone release, the stable fedora repository is frozen. These periods are shown as the Milestone freezes (Beta Freeze, Final Freeze) on schedules. During these periods, builds will not be marked stable and pushed from updates-testing to fedora even after being submitted manually or automatically. In the normal course of events, they will be pushed after the milestone release is approved at a Go_No_Go_Meeting. If you believe your update deserves to break a milestone freeze, a freeze exception may be granted through the freeze exception process. Accepted release blocking bugs are granted the same status through the blocker bug process.

節目となるリリースそれぞれの前に、短い期間で、fedora レポジトリが凍結されます。これらの期間は、予定表には、 Milestone freezes （β版の凍結、最終版の凍結）として表記されています。この期間は、ビルドは、stable とマークされません。updates-testing から fedora までプッシュされません。手動で投稿されていても、自動であってもです。通常のイベントの流れでは、節目となるリリースが Go_No_Go_Meetingで承認されると、パッケージがプッシュされます。もし、あなたのパッケージ更新が、節目となる凍結を壊すと信じるなら、凍結例外 が [[QA:SOP_freeze_exception_bug_process|freeze exception process] を通して、容認されるかもしれません。リリースを妨げるバグとして認められると、blocker bug process を通じて、同じ状態が容認されます。

For more on the Fedora development process, see Fedora Release Life Cycle.

Fedoraの開発工程に関するより詳しいことは、Fedora Release Life Cycleを見てください。

If you are unsure whether your build is currently considered stable for a given release, you can check with koji latest-pkg fXX (where XX is the release).

もしあなたのビルドが、現在 stable と見なされているかどうか分からないなら、koji latest-pkg fXX (XX はリリースを指定)で確認できます。

セキュリティのための更新（Security updates）

There is an additional process that layers over the regular update process for bugs identified as security issues. If a bug is assigned to you that blocks a security tracking bug, you must follow that process in addition to this one.

追加の工程があります。これは、通常のパッケージ更新工程を優先され、セキュリティ問題として認識されたバグに関して存在します。もし、バグがあなたにアサインされ、security tracking bugを妨げているならば、通常の工程に加えて、その工程に従う必要があります。

新しいパッケージの投稿(New package submissions)

If you want to build a new package, but you aren't sure which releases to send it to: 新しいパッケージをビルドしたいが、どのリリースにそれを送るべきか分からない場合:

• New packages should always be built for Rawhide
• New packages can be built for Branched and stable releases if adding them would provide value to users of those releases without significant risk of causing harm

• 新しいパッケージは常にRawhideに対してビルドされるべきです。
• 新しいパッケージはBranchedとStableリリースに対してもビルドされて良いです。それらのリリースを使っているユーザに対して有害となる重大な危険なく、価値を提供できるのであれば、です。

The submission process for new packages, after they have passed the Package_Review_Process and been given an SCM repository, is exactly the same as that for package updates.

Package_Review_Processを通過した後で、かつ、 given an SCM repository　されたら、新しいパッケージを投稿する工程は、パッケージ更新を投稿するプロセスと全く同じです。

パッケージテスト計画作成について考える(Consider creating a package test plan)

If you create test cases for your package, and categorize them appropriately, they will be automatically linked in Bodhi, so that testers will have some guidance for planned update testing.

あなたのパッケージにテストケースを作るとき、そして、テストケースを適当にカテゴリ分けするときは、テストケースは自動的にBodhi の中でリンクされます。その結果、テスト担当者は、計画されたパッケージ更新テストのための手順を得ることができます。