Updates Policy/ja

In other languages: English (en) 日本語 (ja) [edit]

This page is deprecated
FESCo docs have moved to docs.fp.o with source hosted in a pagure repo. This page is now at https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/.

導入（Introduction）

Fedora has differing policies for each of its branches. This document describes for maintainers what sort of updates should be created in packages for each of the various branches of existing Fedora. In the event of questions or clarifications, please file a FESCo trac ticket or discuss on the devel list. In general, releases should go from less conservative (rawhide) to more so (the oldest supported stable release). This document attempts to describe when and what kinds of updates maintainers should push to Fedora users of its various branches. The Stable release updates vision from the Fedora Board includes more high level discussion and philosophy, while this document is more a practical guide. Refer to Package update HOWTO for the technical steps on pushing the updates. The Fedora Release Life Cycle provides a more detailed overview of the development process.

Fedoraは、ブランチごとのポリシーに違いがあります。この文書は、パッケージ保守管理者向けです。既存のFedoraにあるブランチごとのパッケージにどのような種類の更新をすべきかについて記述しています。質問や不明確な点を明確にする場合は、FESCo trac チケット にチケットを追加するか、devel メーリングリストで議論してください。大雑把に言うならば、リリースとは、あまり保守的でない状態（rawhie）からより保守的な状態（最も古く、サポートされた安定リリース）へと変わるべきです。 この文書では、パッケージ保守管理者が、いつ、どのような種類の更新をいろんなブランチを使っているFedoraユーザにプッシュすべきかを述べるように心がけています。Fedora委員会からのStable release updates vision には、より高レベルの議論や哲学が含まれておりますが、このドキュメントはより実践的な入門書です。更新をプッシュするための技術的な手順は、Package update HOWTOを参照してください。Fedora Release Life Cycleには、より詳細な開発工程の概要が述べられています。

Rawhide / devel / master

Rawhide is the always-rolling development tree. Package updates built for rawhide are composed every day and pushed out to all rawhide consumers. There are no "updates" or "updates-testing" Repositories for rawhide. The Bodhi updates system is not used. New builds against this tree also are added to the build root (ie, other packages build from them) daily (usually).

repos available: rawhide

Rawhide は、いつも開発中のツリーです。Rawhide用にビルドされたパッケージの更新は、毎日行われていて、全Rawhideの利用者にプッシュされています。Rawhideには、"updates"や"updates-testing" といったRepositoriesは存在しません。Bodhi更新システムは使われません。Rawhideのツリーに対する新しいビルドもまた、（大抵は）毎日ビルドルートに追加されます（例えばほかのパッケージはそれらからビルドされます）。

利用可能なレポジトリ: rawhide

For updates to rawhide packages, Maintainers SHOULD:

• Try not to push a clearly broken build (breaks the default buildroot package set, etc)
• When a proposed update contains an ABI or API change: notify a week in advance both fedora-devel and maintainers directly (using the packagename-owner@ alias) whose packages depend on yours to rebuild or offer to do these rebuilds for them.
• Use a separate buildsystem tag when dealing with mass builds of many packages, so they can land at the same time. File a ticket with https://fedorahosted.org/rel-eng/newticket for this.
• Feel free to push out the newest version of packages as long as they do not cause breakage. Also keep in mind when the next Fedora release will be branched off, and be fairly confident that there will be a stable enough release in time for the next Fedora release. Otherwise you may have to back down to an older, stable version after the branching, which may involve epochs and other inconveniences.
• If approved by FESCo push pre-release versions of low level packages. Certain low-level packages (approved by FESCo), including (but not limited to) glibc and gcc to provide pre-release versions here. The benefits of the early real-world testing of and upstream collaboration on these key packages far exceeds the risks that they may introduce.

Rawhideパッケージへの更新のため、パッケージ保守管理者は次のことをすべきです:

• デフォルトのビルドルートのパッケージセットを破壊するような、明らかに壊れているビルドをプッシュしないこと。
• 提案された更新に、ABIやAPIの変更が含まれている場合、一週間前に通知すること。通知先は、fedora-devel と あなたのパッケージに依存してるパッケージの保守管理者(packagename-owner@のエイリアスを使って) に直接知らせ、リビルドすること、もしくはリビルドすることを申し出ること。
• たくさんのパッケージの大量にビルドする時には、別々のビルドシステムタグを分けて使うこと。そうすれば、同時にパッケージをビルドできます。この場合は、https://fedorahosted.org/rel-eng/newticket にチケットを発行してください。
• パッケージが何かを壊さない限り、パッケージの私いバージョンを自由にプッシュして良いです。また、次のFedoraリリースがいつ分岐されるのかを覚えておいてください。次のFedoraリリースに間に合うように、安定した十分なリリースがあることを十分に確信してください。さもないと、あなたは古く、安定しているバージョンに戻さねばならないかもしれません。分岐した後では、様々な出来事や不都合を巻き起こす可能性があります。
• もし、FESCoによって承認されたならば、低レベルのパッケージのリリース前のバージョンをプッシュしてください。特定の低レベルのパッケージ（FESCoが承認済みの）には、glibcとgccが含まれていて（これらに限られてはいませんが）、リリース前のバージョンを提供しています。早いうちに現実世界でテストして、パッケージの開発元との協働作業することは、それらが引き起こすかもしれないずっとリスクを上回るメリットがあります。

Branchedリリース（Branched release）

A Branched release exists for part of the development cycle. It is branched off Rawhide and eventually becomes the next stable release. After the Bodhi enabling point, Branched releases do use the update feedback system (Bodhi). There are several "phases" that a branched release goes through that affect what updates can and should be done. In general maintainers should keep in mind that this tree is being used to stabilize for the next release, so changes should be careful and considered and heading toward stability.

Branchedリリースは、開発サイクルの一部です。Branchedリリースは、Rawhideから枝分かれされ、徐々に次の安定したリリースになっていきます。Bodhiが有効になる 地点を過ぎると、Branchedリリースは、パッケージの更新状況をフィードバックしてくれるシステム（Bodhi）を使います。Branchedリリースには、何段階かがあり、何のアップデートができ、また、されるべきかが決まります。一般的にパッケージの保守管理者が留意しておくべきことは、このツリーは、次のリリースに向けて、安定するために使われるということで、変更は十分に注意し考慮されるべきであり、安定に向かっているべきであるということです。

Branched, Bodhiが有効になる前（pre-Bodhi enabling）

For a short time after the branch event happens but before the Bodhi enabling point, the Branched release works just like Rawhide: builds submitted by packagers are considered stable immediately, and sent to the fedora repository directly in the next nightly compose. There are no restrictions beyond those for Rawhide at this point, but maintainers SHOULD be thinking about stabilization from this point onwards, and making sure their packages will be in good condition well in advance of the stable release. Some packages will be signed at this point, but not all of them. You may have to use --nogpgcheck to install or update.

枝分かれが発生した後の短い間で、Bodhiが有効になる前、Branchedリリースは、Rawhideのように機能しています: パッケージ作成者が投稿したビルドは、すぐにstable として扱われます。そして、次の夜のcomposeで、fedora レポジトリに直接送られます。この時点では、Rawhideのビルドと同等の制限しかないのですが、パッケージの保守管理者は、この時点からパッケージを安定させることを考えているべきであり、安定したリリースに先んじて、彼らのパッケージが良い状態にあることを確認しておくべきです。いくつかのパッケージはこの段階でサインされるでしょうが、全部ではありません。あなたは、--nogpgcheck をつけてインストールもしくは、更新しなければならないかもしれません。

有効なレポジトリ: fedora

Bodhiが有効になっている時（Bodhi enabling）

At the Bodhi enabling point, the Bodhi update system is enabled for the Branched release. After this point for the entire remaining lifetime of the release, all updates must go through Bodhi before they can be marked stable and moved to either fedora or updates. At present, the Bodhi enabling point occurs on the day of the Beta freeze, but it is important to remember that they are distinct events: the Beta freeze lasts until Beta release, but Bodhi enabling is permanent.

Bodhiが有効化されると、Bodhi パッケージ更新システムは、Branchedリリースに対して有効となります。この地点を超えると、リリースの残りの生存時間はずっと全ての更新は、Bodhiを通過せねばなりません。パッケージが安定したとマークされ、そして、fedora レポジトリ、もしくは、updatesレポジトリに移動されるまでは。現在は、Bodhi有効化地点は、β版凍結した日になっていますが、重要なのは、β版の凍結は、β版がリリースされるまで続くのに対して、Bodhi有効状態は、ずっと続くという違いがあることを覚えておくことです。

有効なレポジトリ: fedora, updates-testing

At this point all packages will be signed and gpgcheck should be enabled for all installs/updates. この地点では、すべてのパッケージがサインされます。そして、gpgcheckは、すべてのインストール及びアップデートに対して有効となるべきです。

β版の前（Pre Beta）

This is the time between the Bodhi enabling point and the Beta release. During this time we are attempting to stabilize the major versions of software that will be shipped with the final release of the OS. Major updates can be tolerated, but breaking things for early testers should be avoided if possible. Additionally, as we get close to Alpha or Beta releases any change that breaks composes of Live media, install media or testing should be avoided. Packages for Changes should be landing and getting major testing.

repos available: fedora updates-testing

これは、Bodhi有効化地点とβ版リリースとの間の時間です。この時間には、私たちは、ソフトウエアのメジャーバージョンの安定化に努めています。ソフトウエアは、OSの最終版とともに送り出されます。メジャーアップデートは、容認されますが、可能であれば、初期のテストが失敗することは避けるべきです。加えて、α版もしくはβ版に近くに連れて、ライブ媒体、インストール媒体、もしくはテストのcomposeを破壊するようないかなる変更も避けるべきです。Changesに該当するパッケージは、取り上げて、メジャーなテストを受けるべきです。

利用可能なレポジトリ: fedora updates-testing

これ以降パッケージの保守管理者がやらなければいけないことは、:

• Push all updates first to updates-testing.
• All critical path updates MUST either get one +1 karma, OR spend at least 14 days in updates-testing and have no negative karma before being moved to stable.
• All non critical path updates MUST either reach the prescribed karma level for that update, OR spend at least 3 days in updates-testing before being allowed to move to stable.

• すべての更新は、最初に updates-testing レポジトリにプッシュすること
• すべての critical pathに該当するパッケージの更新は、一つの +1 karma、もしくは、最低14日間を updates-testing レポジトリで過ごさなければならず、stableに移動される前に、消極的な karma を持っていないこと。
• critical path に該当しない更新の場合は、事前に定められた、更新時に必要なkarmaレベルに達しているか、最低3日間は、updates-testingレポジトリで過ごしてから、stableに移動されることが許される。

そして、パッケージ保守管理者は、つぎのことを"やったほうが良い"（強制はされない）:

• Avoid ABI/API changes where possible. If unavoidable, should coordinate a side tag to rebuild packages in or a mass build/update, by filing a releng ticket.
• ABI/APIの変更は可能な限り避けること。もし避けられないのであれば、releng チケットを発行し、パッケージをリビルドするために、脇にあるタグを調整するか、一括ビルド/更新をした方が良い。

節目における凍結（Milestone freezes）

During this period there are two Milestone freezes, Alpha freeze and Beta freeze. Each is scheduled to run for the two weeks leading up to the release date (and in fact lasts until the release is signed off, even if it is delayed). During these times, builds will not be marked stable and moved from updates-testing to fedora (and hence included in the milestone release composes) except for those approved under the QA:SOP_blocker_bug_process or QA:SOP_freeze_exception_bug_process. Once the milestone release is made, these freezes are lifted. These freezes are technically not a part of the Updates Policy, but are briefly mentioned here for clarity. The Milestone freezes page provides more details and is the canonical reference in case of any conflict.

この期間には、二つのMilestone freezesがあり、α版の凍結と、β版の凍結があります。いずれも二週間にわたって予定されており、リリース日まで（実際には、遅れていても、リリースが承認されるまで）続きます。この間は、ビルドは、"stable"としてみなされておらず、updates-testingレポジトリからfedoraレポジトリに移動します（つまり、節目のリリースcomposeに含まれます）。ただし、QA:SOP_blocker_bug_process もしくは QA:SOP_freeze_exception_bug_processのもとで承認されるものは除外されます。一旦節目となるリリースが作られると、これらの凍結は解除されます。これらの凍結は、技術的には、Updates Policyの一部ではないのですが、明確にするために簡単に説明されています。Milestone freezes ページにはより詳細な情報が提供されていて、衝突があった場合の標準的な参考文献となっています。

β版から一般公開版リリースまで（Beta to Pre Release）

This is the time between the Beta release and the Final freeze. The branched tree should now be stabilized and prepared for release. Major changes should be avoided during this period. Bear in mind that in most cases, the state your package has reached in the stable fedora repository at the time of the Final freeze is the state it will be in for the final release.

この時間は、β版リリースと最終版の凍結の間です。Branchedのツリーは、最終版リリースの準備のために安定化されて準備されるべきです。大きな変更はこの期間は避けるべきです。気をつけてほしいことは、ほとんどのケースでは、最終版凍結の時点では、fedoraレポジトリにあるあなたのパッケージが安定した状態であり、最終版リリースと同じ状態であるということです。

利用可能なレポジトリ: fedora updates-testing

From this point onwards maintainers MUST:

• Avoid Major version updates, ABI breakage or API changes if at all possible.
• Push updates first to updates-testing.
• All critical path updates MUST either have a sum of +2 karma, OR spend at least 14 days in updates-testing and have no negative karma.
• All non critical path updates MUST either reach the prescribed karma level for that update, OR spend at least 7 days in updates-testing before being allowed to go to stable.

これ以降パッケージの保守管理者が やらなければならないことは、:

• 大きなバージョンアップの更新はしない、ABIの破壊もしくは、APIの変更はしないこと
• 更新は、まずupdate-testingレポジトリに、プッシュすること
• すべての critical path に該当するパッケージの更新は、最低でも合計 +2 karma を得るか、最低14日間をupdates-testingで過ごさねばならず、加えて、消極的な karma を持っていないこと。
• critical path に該当しない更新の場合は、事前に定められた、更新時に必要なkarmaレベルに達しているか、最低 7 日間は、updates-testingレポジトリで過ごしてから、stableに移動されることが許される。

一般公開版リリースの前（Pre release）

This is the time after the Final freeze. During this time the release is being composed and only packages granted exceptions through the QA:SOP_blocker_bug_process or QA:SOP_freeze_exception_bug_process are marked as stable and moved to the fedora repository. The updates repository is enabled at some point during this time, and packages other than freeze exception / blocker fixes are queued for so called "zero day" updates, meaning they will be available in the updates repository at the time of the release (day zero).

これは、最終版の凍結後の時間です。この時間では、リリースが構成され、QA:SOP_blocker_bug_processまたはQA:SOP_freeze_exception_bug_processを介して例外を許可されたパッケージのみが stableとしてマークされ、 fedora レポジトリ に移動されます。 updatesリポジトリはこの間のある時点で有効になり、例外 または blocker以外の凍結されていないパッケージは、"0日"の更新と呼ばれる更新のために、キューイングされます。つまり、それらのパッケージは、リリース時点で、updatesレポジトリの中で利用できるようになります（ゼロ日）。

利用可能なレポジトリ: fedora updates updates-testing

During this period:

• All updates pulled into the release MUST fix an accepted blocker or freeze exception bug.
• All update pushes will go to updates-testing.
• All critical path updates MUST either have a sum of +2 karma, OR spend at least 14 days in updates-testing and have no negative karma.
• All non critical path updates MUST either reach the prescribed karma level for that update, OR spend at least 7 days in updates-testing before being allowed in stable.
• Once the updates repository is available, builds marked as stable will go there instead of to fedora.

この期間は:

• 最終版に反映される全ての更新では リリースをブロックしているバグ、もしくは、凍結時に例外扱いされていたバグが修正されなければなりません
• 全ての更新は、updates-testing レポジトリに行きます。
• すべての critical path に該当するパッケージの更新は、最低でも合計 +2 karma を得るか、最低14日間をupdates-testingで過ごさねばならず、加えて、消極的な karma を持っていないこと。
• critical path に該当しない更新の場合は、事前に定められた、更新時に必要なkarmaレベルに達しているか、最低 7 日間は、updates-testingレポジトリで過ごしてから、stableに移動されることが許される。
• 一旦updatesレポジトリが有効になると、stableであるビルドは、updatesレポジトリに行きます。fedoraレポジトリには行きません。

一般公開版のリリース（Stable Releases）

哲学（Philosophy）

Releases of the Fedora distribution are like releases of the individual packages that compose it. A major version number reflects a more-or-less stable set of features and functionality. As a result, we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience. The update rate for any given release should drop off over time, approaching zero near release end-of-life; since updates are primarily bugfixes, fewer and fewer should be needed over time.

Fedora配布物のリリースは、リリースを構成している個々のパッケージのリリースに似ています。メジャーバージョンの番号は、安定した特徴と機能のセットの量に影響されます。結果として、安定版のリリースに含まれるパッケージのメジャーな更新は避けるべきです。更新はバグ修正を目的とすべきで、特徴的な機能の導入はすべきではなく、特にユーザまたは開発者が使った時にいちじるしく影響を与えるであろう機能は特に導入すべきではありません。更新頻度は時間とともに落ちていくべきで、リリースが保守管理されなくなる、ご臨終（EOF）に近くなると、ゼロに近づいて行きます; 従って、更新は主にバグ修正で、時間が経つにつれて必要な数は少なくなります。

This necessarily means that stable releases will not closely track the very latest upstream code for all packages. We have rawhide for that.

これは、必然的に、安定版のリリースが、全てのパッケージにおいて、最新の開発元のコードを追跡していません。

Rebases should be carefully considered with respect to their dependencies. A rebase that required (or provided) a new Python ABI, for example, would almost certainly not be allowed. ABI changes in general are very strongly discouraged, they force larger update sets on users and they make life difficult for third-party packagers. Additionally, updates that convert resources or configuration one way (ie, from older->newer) should be approached with extreme caution as there would be much less chance of backing out an update that did these things.

リベースは、依存関係の点で気をつけて考える必要があります。例えば新しいPython ABIを要求する（もしくは提供する）リベースは、ほとんどの場合、確実に許されないでしょう。ABIの変更は、大抵の場合、まったくおすすめされません。その変更が、ユーザに多大なる更新を強制し、サードパーティーのパッケージ作成者にとって対応が難しくなります。加えて、リソースや設定を一方向（例えば、古いものから新しいものへ）にだけ変更する更新は、特別な注意をもって、採用されるべきです。その更新は、変更を及ぼす更新を元に戻すチャンスが少ないです。

Whenever possible packagers should work with upstream to come up with stable branch releases or common patches for older releases, particularly when rebasing would require large dependency chain updates.

パッケージ作成者は、可能な限り、開発元と強調して、安定したブランチのリリースに追随すべきです。または、共通のパッチを古いリリースに対して提供すべきです。これは、特に、リベースが広範囲の依存関係の更新が必要となる場合では、そうすべきです。

repos available: fedora updates updates-testing

利用可能なレポジトリ: fedora updates updates-testing

重要パッケージへの更新（Updates to 'critical path' packages）

Updates that constitute a part of the 'critical path' package set (defined below) including security updates MUST follow the rules as defined for critical path packages for pending releases, meaning:

• At the time of the request to stable, the update needs to have either a Bodhi karma sum of 2 OR
• It must spend at least 14 days in updates-testing AND have no negative Bodhi karma points.

セキュリティのための更新を含む、'critical path'パッケージセット（下で定義している）の一部を構成する更新では、正式リリース前の間は、critical path packagesとして定義されたルールに従わなければなりません。

• At the time of the request to stable, 更新には、合計 2 Bodhi karma、もしくは
• updates-testingレポジトリに、最低 14 日間存在し、かつ 否定的な Bodhi karma ポイントがないこと。

For the purposes of this policy, the 'critical path' package set is defined as the following:

• The current critical path package set
• All major desktop environments' core functionality (GNOME, KDE, Xfce, LXDE)
• Package updating frameworks (gnome-packagekit, apper)
• Major desktop productivity apps. An initial list would be firefox, kde-baseapps (konqueror), thunderbird, evolution, kdepim (kmail).

このポリシーの目的は、'critical path'パッケージが、次のように定義されていることによります:

• 現在critical path package set
• 主要なデスクトップ環境のコア機能 (GNOME, KDE, Xfce, LXDE)
• パッケージ更新フレームワーク (gnome-packagekit, apper)
• 主要なデストップ生産性向上のためのアプリ初期リストは、 firefox, kde-baseapps (konqueror), thunderbird, evolution, kdepim (kmail)です。

Changes to this definition may only be made by FESCo or their delegate. この定義への変更は、FESCoもしくはその代理人によってのみおこなわれます。

その他全ての更新（All other updates）

All other updates MUST either:

• reach the criteria laid out in the previous section OR
• reach the positive Bodhi karma threshold specified by the updates submitter OR
• spend some minimum amount of time in updates-testing, currently one week

Package maintainers MUST:

• Avoid Major version updates, ABI breakage or API changes if at all possible.
• Avoid changing the user experience if at all possible.
• Avoid updates that are trivial or don't affect any Fedora users.

Package maintainers SHOULD:

• Push only major bug fixes and security fixes to the previous stable releases (i.e., at present, Fedora 40 and before).

その他全ての更新における必須条件は、次のいずれかです:

• 前のセクションで述べた基準に達している もしくは
• 肯定的な karma 数が、更新を投稿した人が指定している閾値に達している もしくは
• updates-testingレポジトリ滞在時間。現在は最低一週間。

パッケージ保守管理者は、次のことを守らねばなりません:

• メジャーバージョンの更新、ABIの破壊、APIの変更は、最大限回避すること。
• ユーザの使い勝手を変更することは、最大限回避すること。
• 小さな、もしくは、Fedoraユーザに影響しない更新は避けること。

パッケージ保守管理者は、次のことを進んでやると良いです:

• 以前の安定版に対する大きなバグ修正とセキュリティ修正のみをプッシュする（例えば、現在であれば、Fedora 40 とそれ以前のバージョン）

例外（Exceptions）

Some classes of software will not fit in these guidelines. If your package does not fit in one of the classes below, but you think it should be allowed to update more rapidly, propose a new exception class to FESCo and/or request an exception for your specific update case.

ソフトウエアのいくつかのクラスは、これらのガイドラインに合致しないでしょう。もしあなたのパッケージが以下に挙げるクラスの一つで、合致せず、しかし、早急に更新が許されるべきであると考える場合は、FESCoに新しい例外クラスとして、提案してください。そして（または）あなたの指定したパッケージ更新のケースを例外にするように要求してください。

Note that you should open this dialog BEFORE you build or push updates. In the event that an issue is raised in the middle of an update already in progress, make sure you turn off autokarma pushes — this can be done while the update is pending in bodhi.

あなたは、更新をビルド、もしくは、プッシュするよりも前に、この議論を始めるべきであることに注意してください。更新がすでに進行中の真っ最中に議案が挙げられるときは、自動karmaによりプッシュする機能がオフになっていることを確認してください。- これは、Bodhiでアップデートが中断している間は、設定できます。

The following things would be considered in a exception request.

例外にするように要求する時に、次のことが考慮されます。

Things that would make it more likely to grant a request: 要求を認められやすくなること:

• The package is a "leaf" node. Nothing depends on it or requires it.
• The update fixes a security issue that would affect a large number of users.
• The update doesn't change ABI/API and nothing needs to be rebuilt against the new version.
• The update fixes serious bugs that many fedora users are encountering.

• そのパッケージが"葉っぱ"であり、他のパッケージから依存されていたり、要求されていない。
• その更新がセキュリティの問題を修正し、その問題が多くのユーザに影響を与えうる。
• その更新では、ABI/APIが変更されず、新しいバージョンに対してリビルドが不要。
• その更新は、重大な不具合を修正する。その不具合が多くのFedoraユーザが遭遇すると考えうる。

Things that would make it less likely to grant a request: 要求を認められにくくなること:

• The update converts databases or resources one way to a new format.
• The update requires admin intervention for the service to keep working (config file format changes, etc)
• The update causes behavior changes (something that was denied is allowed, etc)
• The update changes the UI the end user sees (moves menus or buttons around, changes option names on command line)
• The update fixes bugs that no fedora user has reported nor would affect many fedora users (ie, fixes for other platforms or configurations).

• 更新すると、データベースやリソースを新しいフォーマットに変更され、元に戻せない。
• 更新するためには、サービスが稼働し続けるには、管理者の介入が必要（設定ファイルフォーマット変更など）。
• 更新すると、挙動が変わる（拒否されていたことが許可されるなど）。
• ユーザに見えていたUIが変わる（メニューやボタンが移動したり、コマンドラインのオプション名が変更される）
• 更新すると、Fedoraユーザがレポートしていない、もしくは、多くのFedoraユーザには影響しない不具合が修正される（例えば、他のプラットフォームに対する修正や設定）

例外の一覧（Exceptions list）

The following packages have been granted exceptions for the following reasons:

次のパッケージは、更新が例外的に容認されています。理由は以下の通りです:

カーネルパッケージ（kernel package）

• Manpower of kernel maintainers prevents us from easily backporting all the bug fixes, security fixes and new hardware enablement we would need to maintain older, no longer supported kernels.

• Additionally, multiple kernels can be installed/booted, allowing users to boot older kernels in the event newer ones fail to work, and allowing time for kernel maintainers to fix any critical bugs in new kernels on older stable releases.

• カーネル保守管理者の人手では、古くてサポートされてないカーネルを維持するために必要な全ての不具合修正やセキュリティ修正、新しいハードウエアを有効にすることは簡単にバックポート（訳注：古いカーネルに対してパッチを移植すること）はできません。

• 加えて、複数のカーネルをインストールして起動することもできます。ユーザは古いカーネルを起動できます。新しいカーネルは起動に失敗することもあるでしょう。そして、カーネル保守管理者は、古い安定したFedoraリリース上で、新しいカーネルの重大な不具合を修正できます。

KDE

Refer to the KDE update policy for more details 詳細は、KDE update policyをみてください。

girara と zathura（girara and zathura）

These packages are allowed to update in stable releases together. See https://fedorahosted.org/fesco/ticket/1255 これらのパッケージは、ともに安定版リリースでも更新が許されています。 https://fedorahosted.org/fesco/ticket/1255 をみてください。

セキュリティ修正（Security fixes）

If upstream does not provide security fixes for a particular release, and if backporting the fix would be impractical, then the package maintainer(s) MUST open a FESCo ticket for approval to rebase the package to a version that upstream supports. ソフトウエア開発元が特定のリリースに対するセキュリティ修正を提供しない場合、そして、修正を以前のバージョンに移植することが非現実的な場合、パッケージ保守管理者は、FESCoにチケットを切って、ソフトウエア開発元がサポートしているバージョンに戻す（リベースする）承認を得なければなりません。

Package maintainers MUST:

• Avoid Major version updates, AI breakage, or API changes if at all possible
• Avoid changing the user or developer experience if at all possible

パッケージ保守管理者は、次のことを守らねばなりません:

• メジャーバージョンの更新、ABIの破壊、APIの変更は、最大限回避すること。
• ユーザの使い勝手を変更することは、最大限回避すること。

FESCo will review the ticket in a timely manner and give guidance as to how the package maintainer(s) should proceed. By way of information, several common items that would make it less likely for FESCo to grant a rebase request are listed below. Please note, however, that this list is not exhaustive. FESCoは、適時チケットをレビューし、パッケージ保守管理者がどう進めるべきかを助言します。物によっては、FESCoがリベース要求を容認しにくくする、いくつかの一般的なことを以下にリストします。しかし、このリストは、すべてを網羅していないので、注意してください。

FESCo will be less likely to grant a rebase request if:

• The update requires user or administrator intervention to keep working
• The update requires configuration files or databases or other resources to convert to a new format
• The update causes policy or behavior changes (such as when something that was previously denied is now allowed, etc.)
• The update changes the way the end user interacts with the user interface (such as moving menus or buttons to a new location, changing names of command-line arguments, etc.)
• The rebase only addresses issues that are likely to affect a subjectively small number of Fedora users

FESCo は、以下の場合、リベース要求を容認しにくくなります:

• 更新するには、ユーザもしくは管理者が介在して有効にする必要がある
• 更新すると、データベースやリソースを新しいフォーマットに変更され、元に戻せない。
• 更新すると、挙動が変わる（拒否されていたことが許可されるなど）。
• ユーザに見えていたUIが変わる（メニューやボタンが移動したり、コマンドラインのオプション名が変更される）
• リベースすると、主観的に少数のFedoraユーザーに影響を与える可能性がある問題のみを扱います。

例外扱いのパッケージ（Packages with Exceptions Granted）

• kernel

相互運用性（Interoperability）

If a package primarily serves to interoperate with hardware or network protocols, and the interface changes, then a package may be rebased if necessary. This includes network games, IM protocols, hardware music players, cell phones, etc. These packages may also be updated to add support for new devices or formats in compatible ways.

Examples of this type of package: libopenraw, libimobiledevice, calibre, pilot-link

もしパッケージが主にハードウエアもしくはネットワークプロトコルと相互運用に寄与する場合、そして、そのインターフェースが変更した場合、パッケージは必要に応じて、リベースするかもしれません。これには、ネットワークゲーム、インスタントメッセージングプロトコル、音楽プレーヤー、携帯電話などが含まれます。これらのパッケージは、新しいデバイスや互換性のあるフォーマットのサポートが追加される時にも更新されるかもしれません。

このタイプのパッケージ例: libopenraw, libimobiledevice, calibre, pilot-link

データベースパッケージ（Database packages）

Packages like virus scanners and spam filters typically have two components: a rules engine and a database. The database is expected to update frequently (sometimes not through the normal OS update mechanisms), but the rules engine is usually fairly static. However, if the maintained database changes to require a new version of the rules engine, then the package may be a candidate for rebasing.

Examples of this type of package: spamassassin, clamav

ウイルススキャナとスパムフィルタのようなパッケージは、大抵の場合、二つのコンポーネントがある: ルールエンジンとデータベース。データベースは頻繁に更新することが予想される（時には、通常のOS更新のメカニズムを経由しない）が、ルールエンジンは、大抵ほとんど更新されない。しかし、もしデータベースがルールエンジンの新しいバージョンを必要とする変更が発生したならば、パッケージはリベースをする候補となるかもしれません。

このタイプのパッケージ例: spamassassin, clamav

例（Examples）

• Mozilla releases Firefox 4.0.1 with a security fix. Fedora 12 is shipping with 3.0.7, and though the bug is also present there, the fix in 4.0.1 does not apply because that part of the browser has been completely rewritten. Rebasing to 4.0.1 would be allowed since this is a security fix.

• Mozilla は Firefox 4.0.1 をセキュリティフィックスでリリースしました。Fedora 12 には 3.0.7で出荷されていて、この不具合がありました。4.0.1 の修正は、適用されませんでした。何故ならば、ブラウザの一部が完全に書き換えられていたためです。4.0.1にリベースすることは、セキュリティの修正一個であれば、許可されたでしょう。

• automake releases a new version that changes some warning conditions to errors. This would break the build process for existing packages, and would not be allowed.

• automake の新しいバージョンがリリースされて、警告条件であったものが、エラーに変わっています。これは、既存パッケージのビルド工程を破壊するでしょうから、許容されないでしょう。

• AOL changes their instant messenger protocol in a way that requires an update to libpurple. The only upstream version of libpurple that supports the new protocol is an ABI break relative to the version in the current Fedora release. Rebasing would be allowed since this is an interoperability requirement.

• AOL がインスタントメッセンジャーのプロトコルを変えます。これには、libpurpleぱっけーじの更新が必要となります。libpurpleの開発元のバージョンだけが、新しいプロトコルをサポートしています。現在Fedoraのリリースに含まれているバージョンと比較すると、ABIの破壊が起きています。これは相互運用が必要であるという理由で、リベースは許可されるでしょう。

• Abiword releases a new version that adds compatibility with WordStar 4.0 documents. It also completely updates the user interface to use pie menus. This would be a feature enhancement with a major user experience change, and would not be allowed.

• Abiword は、WordStar 4.0の文書と互換機能を新しいバージョンに追加しました。それはまた、ユーザインターフェースを完全に刷新し、パイメニューを使うようになります。これは、大半のユーザの使い勝手を変える機能追加で、リベースは許可されません。

• WebKit requires an update to solve a security problem. This requires updating Midori to a version with some minor menu layout changes. This would be a judgement call based on how intrusive the changes are (removing the File menu would be rude, but moving the plugin configuration menu item would be acceptable).

• WebKit がセキュリティ問題を解決するために更新を要求しています。Midori をアップデートする必要があり、小さなメニューの構成変更が生じます。これは、変更がどの程度で邪魔であるかにより、判断されるでしょう(ファイルメニューを削除することは、失礼ですが、プラグインの設定メニュー項目を移動するのであれば、受容されるでしょう）。

• Firefox releases an update that only contains changes for other platforms. This update could be pushed to rawhide (just to keep up with the latest version), but should not be pushed to stable releases, as it does no good to our users and wastes resources to build, update, mirror and download to our users.

• Firefox が他のプラットフォーム向けの変更を含んだだけの更新をしました。この更新は、Rawhideにプッシュされます（最新バージョンに追随しただけ）。しかし、安定版のリリースには、プッシュすべきではありません。なぜなら、私たちのユーザにとって良いものではないし、ビルド、更新、ミラー、そして、ユーザへのダウンロードするためのリソースが無駄になるから。

• Terminal fails to build from source when tested in a mass rebuild. An updated package should be pushed to rawhide. Fixes for stable releases should be tested and even commited, but unless there is a problem with the previous existing build in the stable release, no update should be issued. This update would not change any user facing functions of the package.

• 大量にリビルドしている中でテストする時に、ターミナルは、ソースからビルドできません。更新されたパッケージは、Rawhideにプッシュされるべきです。安定版リリース向けの修正は、テストされてコミットされるべきです。しかし、安定版リリースで以前から存在しているビルドに問題がないのであれば、更新はされるべきではありません。この更新はパッケージのユーザが使っている関数は変わっていないでしょうから。

• KDE upstream releases a new major version, and at the same time stops supporting the older release that is in Fedora N and Fedora N-1. This release includes a large number of bugfixes, mixed with enhancements and security fixes. An exception for this type of update would need to consider: ability to backport major fixes/security issues, type and amount of bugs fixed, ability to not update other parts of fedora for this update (ie, avoid qt or other base library ABI changes), amount of testing and end user visible changes. An exception like this would be on a case by case bases based on all the above.

• KDE開発元は、新しいメジャーバージョンをリリースしています。同時に、古いリリースのサポートを停止しています。古いリリースは、Fedora NとFedora N-1に含まれています。このリリースには、大量のバグ修正と、機能追加、とセキュリティ修正が混ざっています。このような更新の例外は、考慮される必要があります: 主要な修正/セキュリティ問題、問題の種類、バグ修正の量、アップデートによって、Fedoraの他の部分が更新されないか（例えば、QTもしくは、他の基本となるライブラリのABIの変更）、テストの量、エンドユーザに見える部分の変更。このような例外は、上にあげた全てに基づき、ケースによるでしょう。

更新に付随する問題及び課題（Problems or issues with Updates）

In an effort to learn from any mistakes made, in the event of a update causing a widespread or serious problem for Fedora users, please file a FESCo trac ticket. FESCo will discuss and try and work to prevent the issue from happening again. A past record of such issues can be found at Updates Lessons.

FESCo will work with QA and others to prevent or mitigate the issue.

Fedoraユーザにとって広範囲で重大な問題を引き起こす更新の場合、間違いから学ぶ努力として、FESCo trac チケットに追加してください。FESCoは、議論して、その問題が二度と起きないようにしようとするでしょう。そのような問題の過去の記録は、Updates Lessonsで見つけられます。

FESCo は QA及びその他の人々と一緒に、その問題を予防するかもしくは、軽減するでしょう。

お互いに依存関係にあるパッケージの更新（Updating inter-dependent packages）

When one updated package requires another (or more than one other), the packages should be submitted together as a single update. For instance, if package A depends on packages B and C, and you want to update to a new version of package A which requires new versions of B and C, you must submit a single update containing the updated versions of all three packages. It is a bad idea to submit three separate updates, because if the update for package A is pushed stable before the updates for packages B and C, it will cause dependency problems. There is information on how to submit multi-package updates in the package update HOWTO.

あるパッケージの更新が、もう一つ（もしくはそれ以上）の更新を必要とするとき、パッケージは一個の更新として投稿されるべきです。例えば、パッケージAが、B, Cに依存していて、あなたが、パッケージAの新しいバージョンを更新したく、パッケージAは、パッケージB,Cの新しいバージョンを必要としていたら、三つ全てのパッケージの更新されたバージョンを含んだ一つの更新を投稿しなければなりません。三つ別々に更新を投稿するのは、悪い考えです。何故ならば、パッケージB及びCの更新より前にパッケージAの更新が安定版にプッシュされると、依存関係に問題が生じます。複数のパッケージ更新のやり方は、package update HOWTOにあります。

Taskotron

The Taskotron automated testing system runs two tests against all updates submitted to Bodhi: a dependency check (to ensure all dependencies of the package(s) can be fulfilled from the repositories) and an upgrade path check (to ensure the update does not break the upgrade path from release to release, i.e. that the update does not contain a package versioned higher than the newest version of the same package available in a later Fedora release). Taskotron adds comments to Bodhi with the results of these test runs. A failure of either test will cause Bodhi#Karma_Automatism for the update to be disabled (if it was enabled). If you submit an update that fails one of these tests, please check the result and fix the problem. If you are sure the failure is an error in the test rather than an error in your package, you may still manually push the update or re-enable karma automatism.

Previously, the old AutoQA system ran similar checks to Taskotron. The scope of these automated checks is expected to expand in future. The QA:Package_Update_Acceptance_Test_Plan was written as the original plan for AutoQA update validation, and may still be seen as a framework for future work on Taskotron.

Taskotron 自動テストシステムは、Bodhiに投稿された全ての更新に対して、二つのテストを実行します: 依存関係のチェック（パッケージの全ての依存関係がそのレポジトリの中で解決できるかを確認する）とアップグレードパスのチェック（リリースからリリースへのアップグレードパスを壊していないことを確認する。例えば、更新には、それ以降のFedoraで利用可能な、同一パッケージの最新バージョンよりも新しいバージョンのパッケージは含まれていないことを確認する）。Taskotron は、Bodhiにこれらのテスト結果とともにコメントを追加します。いずれかのテストが失敗した場合は、Bodhi#Karma_Automatism となり、更新はできない状態となります（もし更新ができる状態だったならば）。あなたは、テストの失敗した更新を投稿するならば、結果を確認して、問題を修正してください。もし、あなたのパッケージ中で発生しているエラーではなく、テストが失敗していると確認する場合は、手動で更新をプッシュして、 karma automatismを再度有効にしてもよいでしょう。

古い自動QAシステムでは、Taskotonに似たチェックをしていました。これらの自動チェックの範囲は、将来的に拡大することが期待されています。QA:Package_Update_Acceptance_Test_Plan は、AutoQAの更新検証のための最初の計画として書かれました。そしてそれは、Tasktronの将来の仕事のフレームワークとみなされるかもしれません。

Bodhiの利用（Bodhi Use）

Bodhi is meant as the method for getting updates into an existing release or pre-release. It does provide a testing mechanism to make sure that nothing unforeseen will arise, but the expectation is that packages submitted are likely ready to ship as an update. As such, any packages submitted to bodhi must be done with the intent that the package submitted is ready for general consumption. The users kind enough to test these packages have come to expect this, and doing anything else moves against their good will, and is likely to drive testers away. Bodhi and updates-testing are not a place for experimentation or advanced notification of potentially disruptive updates. These should be handled with packages in Copr or another public repository with a message to call for testing on the appropriate mailing lists.

Bodhiは、すでにリリースした公開版もしくは、公開予定のpre-releaseに対して、更新するための手段を意味します。テストのメカニズムを提供し、予想外のことを引き起こさないようにします。しかし、投稿されたパッケージが、更新をして、出荷できる状態にありそうかどうかを予想されます。そのようにして、Bodhiに投稿されたパッケージは全て、一般的に利用できる状態であることを意図してBodhiに実行されなければなりません。これらのパッケージをテストするユーザは、それを期待するようになっていて、彼らの意志に反して動くと、テストターはいなくなってしまいそうです。Bodhiとupdates-testingレポジトリは、実験や潜在的な破壊的更新を先んじて通知するための場所ではありません。それらは、Coprもしくは、公開レポジトリのパッケージにおき、然るべきメーリングリストでテストを求めるメッセージとともに、処理すべきです。