「DeveloperWiki:パッチ」の版間の差分
ナビゲーションに移動
検索に移動
(セクション見出しの訳出) |
細 (言語間リンクの修正) |
||
(同じ利用者による、間の5版が非表示) | |||
1行目: | 1行目: | ||
[[カテゴリ:DeveloperWiki]] |
[[カテゴリ:DeveloperWiki]] |
||
− | [[ |
+ | [[en:DeveloperWiki:Patching]] |
− | = パッチ = |
+ | == パッチ == |
+ | |||
− | This policy is intended to *suggest*, not to enforce. |
||
+ | このポリシーは *提案* することを目的としていて、強制ではありません。 |
||
=== バニラパッケージ === |
=== バニラパッケージ === |
||
+ | |||
− | Arch tries, as much as possible, to ship packages as the original author of the software intended. This means that every time we add a patch, we take one more step away from their intent. Additionally, patches can be hard to maintain when we're talking hundreds of packages. |
||
+ | Arch は可能な限り元の作者の意図の通りにパッケージを提供しようとしています。これは、パッチを追加するときは毎回彼らの意図から一歩ずつ外れていくということを意味します。加えて、たくさんのパッケージを管理していると、パッチの維持は困難になります。 |
||
=== パッチが許される場合 === |
=== パッチが許される場合 === |
||
− | It's inevitable that some software will need modifications to work. |
||
+ | いくつかのソフトウェアで機能させるために修正が必要になることは避けられません。 |
||
− | * Patches to the *build system* are pretty much always allowed. This is usually needed when Arch's tools are too new for shipped scripts, and things do not work right (libtool is a known offender here). |
||
+ | * *ビルドシステム* へのパッチはほとんどいつでも許されています。これは普通 Arch のツールが元のスクリプトに対して新しすぎて、うまく動かない場合に必要になります(libtool はよくパッチを当てられます)。 |
||
− | * Patches due to a *too new* compiler are usually allowed. GCC releases tend to be more and more strict, disallowing things that were once allowed. Fixing compiler errors so that the source builds under Arch are common and allowable. |
||
+ | * *新しすぎる* コンパイラが原因のパッチは普通許されています。GCC リリースはより厳密になる傾向にあり、過去に許されていたものが許されなくなってきています。コンパイラエラーを修正してソースを Arch 上でビルドできるようにすることは一般的で容認できます。 |
||
− | |||
+ | * アプリケーションの *主要な機能* が動かないときは、バグフィックスのパッチが許されています。'主要な機能' を説明するために、DVD を書き込むアプリケーションについて考えてください。そのアプリケーションがバグにより DVD に書き込めないときは、主要な機能とみなされます。'ヘルプ' メニューが動かないときは、主要でない機能とみなされます。 |
||
− | * When a *major feature* doesn't work in the app, bug fix patches are allowed. To explain 'major feature', think of an app that burns DVDs - if it doesn't burn DVDs due to a bug, well, that's a major feature. If the 'Help' menu doesn't work, well, that's a minor feature. |
||
=== パッチが推奨されない場合 === |
=== パッチが推奨されない場合 === |
||
− | * Fixing minor features is not our job and patches should not be applied to fix things not directly related to the app's functionality. Patches to fix typos or images are discouraged. |
||
− | |||
− | * Additional features should *NOT* be added by Arch. Patches that add completely new features should be sent to upstream. As said before - we ship packages as the ORIGINAL AUTHORS intended them. Not as WE intend them. |
||
+ | * 主要でない機能の修正は私達の仕事ではなく、パッチはアプリケーションの機能に直接関係ないことを修正するために適用されるべきではありません。タイポや画像の修正のためのパッチは推奨されません。 |
||
− | * Features denied by upstream. If a patch was sent and the original developers denied it, we should *NEVER* apply that patch, no matter how opinionated we are. You are welcome to fork the app and supply a package for your own app. |
||
+ | * 追加の機能は Arch によって追加されるべき *ではありません*。完全に新しい機能を追加するパッチはアップストリームに送られるべきです。上で述べた通り、'''元の作者の''' 意図した通りにパッケージを提供します。我々の意図した通りではありません。 |
||
+ | * アップストリームによって拒否された機能。パッチを送って元の開発者が拒否した場合、我々の思いに関係なくパッチを適用するべき *ではありません*。自由にアプリケーションをフォークして、そのアプリケーションにパッチを適用することができます。 |
2020年5月5日 (火) 14:21時点における最新版
パッチ
このポリシーは *提案* することを目的としていて、強制ではありません。
バニラパッケージ
Arch は可能な限り元の作者の意図の通りにパッケージを提供しようとしています。これは、パッチを追加するときは毎回彼らの意図から一歩ずつ外れていくということを意味します。加えて、たくさんのパッケージを管理していると、パッチの維持は困難になります。
パッチが許される場合
いくつかのソフトウェアで機能させるために修正が必要になることは避けられません。
- *ビルドシステム* へのパッチはほとんどいつでも許されています。これは普通 Arch のツールが元のスクリプトに対して新しすぎて、うまく動かない場合に必要になります(libtool はよくパッチを当てられます)。
- *新しすぎる* コンパイラが原因のパッチは普通許されています。GCC リリースはより厳密になる傾向にあり、過去に許されていたものが許されなくなってきています。コンパイラエラーを修正してソースを Arch 上でビルドできるようにすることは一般的で容認できます。
- アプリケーションの *主要な機能* が動かないときは、バグフィックスのパッチが許されています。'主要な機能' を説明するために、DVD を書き込むアプリケーションについて考えてください。そのアプリケーションがバグにより DVD に書き込めないときは、主要な機能とみなされます。'ヘルプ' メニューが動かないときは、主要でない機能とみなされます。
パッチが推奨されない場合
- 主要でない機能の修正は私達の仕事ではなく、パッチはアプリケーションの機能に直接関係ないことを修正するために適用されるべきではありません。タイポや画像の修正のためのパッチは推奨されません。
- 追加の機能は Arch によって追加されるべき *ではありません*。完全に新しい機能を追加するパッチはアップストリームに送られるべきです。上で述べた通り、元の作者の 意図した通りにパッケージを提供します。我々の意図した通りではありません。
- アップストリームによって拒否された機能。パッチを送って元の開発者が拒否した場合、我々の思いに関係なくパッチを適用するべき *ではありません*。自由にアプリケーションをフォークして、そのアプリケーションにパッチを適用することができます。