DeveloperWiki:パッチ - 版の履歴

Ny-a: 言語間リンクの修正

2020-05-05T05:21:15Z

言語間リンクの修正

← 古い版		2020年5月5日 (火) 14:21時点における版
1行目:		1行目:
	[[カテゴリ:DeveloperWiki]]		[[カテゴリ:DeveloperWiki]]
	[[~~en:~~en:DeveloperWiki:Patching]]		[[en:DeveloperWiki:Patching]]
	== パッチ ==		== パッチ ==

Ny-a: /* パッチが推奨されない場合 */ 訳出

2020-05-05T05:17:04Z

パッチが推奨されない場合: 訳出

← 古い版		2020年5月5日 (火) 14:17時点における版
18行目:		18行目:

	=== パッチが推奨されない場合 ===		=== パッチが推奨されない場合 ===
	* 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.
			* 追加の機能は Arch によって追加されるべきではありません。完全に新しい機能を追加するパッチはアップストリームに送られるべきです。上で述べた通り、'''元の作者の''' 意図した通りにパッケージを提供します。我々の意図した通りではありません。

			* アップストリームによって拒否された機能。パッチを送って元の開発者が拒否した場合、我々の思いに関係なくパッチを適用するべきではありません。自由にアプリケーションをフォークして、そのアプリケーションにパッチを適用することができます。
	* 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.

Ny-a: /* パッチが許される場合 */ 訳出

2020-05-05T05:16:33Z

パッチが許される場合: 訳出

← 古い版		2020年5月5日 (火) 14:16時点における版
10行目:		10行目:

	=== パッチが許される場合 ===		=== パッチが許される場合 ===
	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.

	=== パッチが推奨されない場合 ===		=== パッチが推奨されない場合 ===

Ny-a: /* バニラパッケージ */ 訳出

2020-05-05T05:15:24Z

バニラパッケージ: 訳出

← 古い版		2020年5月5日 (火) 14:15時点における版
6行目:		6行目:

	=== バニラパッケージ ===		=== バニラパッケージ ===

	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 は可能な限り元の作者の意図の通りにパッケージを提供しようとしています。これは、パッチを追加するときは毎回彼らの意図から一歩ずつ外れていくということを意味します。加えて、たくさんのパッケージを管理していると、パッチの維持は困難になります。

	=== パッチが許される場合 ===		=== パッチが許される場合 ===

Ny-a: /* パッチ */ 訳出

2020-05-05T05:15:05Z

パッチ: 訳出

← 古い版		2020年5月5日 (火) 14:15時点における版
2行目:		2行目:
	[[en:en:DeveloperWiki:Patching]]		[[en:en:DeveloperWiki:Patching]]
	== パッチ ==		== パッチ ==

	This policy is intended to suggest, not to enforce.
			このポリシーは提案することを目的としていて、強制ではありません。

	=== バニラパッケージ ===		=== バニラパッケージ ===

Ny-a: /* パッチ */ style: heading level

2020-05-05T05:14:37Z

パッチ: style: heading level

← 古い版		2020年5月5日 (火) 14:14時点における版
1行目:		1行目:
	[[カテゴリ:DeveloperWiki]]		[[カテゴリ:DeveloperWiki]]
	[[en:en:DeveloperWiki:Patching]]		[[en:en:DeveloperWiki:Patching]]
	= パッチ =		== パッチ ==
	This policy is intended to suggest, not to enforce.		This policy is intended to suggest, not to enforce.

Ny-a: セクション見出しの訳出

2020-05-05T05:14:12Z

セクション見出しの訳出

← 古い版		2020年5月5日 (火) 14:14時点における版
1行目:		1行目:
	[[~~Category~~:DeveloperWiki]]		[[カテゴリ:DeveloperWiki]]
	= Patching =		[[en:en:DeveloperWiki:Patching]]
			= パッチ =
	This policy is intended to suggest, not to enforce.		This policy is intended to suggest, not to enforce.

	=== ~~Vanilla Packages~~ ===		=== バニラパッケージ ===
	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 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.

	=== ~~When is patching acceptable?~~ ===		=== パッチが許される場合 ===
	It's inevitable that some software will need modifications to work.		It's inevitable that some software will need modifications to work.

15行目:		16行目:
	* 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.		* 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.

			=== パッチが推奨されない場合 ===
	=== When is patching discouraged? ===
	* 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.		* 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.

Ny-a: en:DeveloperWiki:Patching の版 600498 に同期

2020-05-05T05:12:39Z

en:DeveloperWiki:Patching の版 600498 に同期

新規ページ

[[Category:DeveloperWiki]]
= Patching =
This policy is intended to *suggest*, not to enforce.

=== Vanilla Packages ===
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.

=== When is patching acceptable? ===
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).

* 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.

* 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.

=== When is patching discouraged? ===
* 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.