名前¶
perlpolicy - Various and sundry policies and commitments related to the Perl core
perlpolicy - Perlコアにまつわるさまざまな方針、公約
説明¶
This document is the master document which records all written policies about how the Perl 5 Porters collectively develop and maintain the Perl core.
この文書は Perl 5 Porters が共同でどう Perl のコアを開発、 維持していくかという方針をまとめたものです。 この文書(の原文)が原本であり、明文化された方針はすべてこの文書に 記録されます。
GOVERNANCE¶
Perl 5 Porters¶
Subscribers to perl5-porters (the porters themselves) come in several flavours. Some are quiet curious lurkers, who rarely pitch in and instead watch the ongoing development to ensure they're forewarned of new changes or features in Perl. Some are representatives of vendors, who are there to make sure that Perl continues to compile and work on their platforms. Some patch any reported bug that they know how to fix, some are actively patching their pet area (threads, Win32, the regexp -engine), while others seem to do nothing but complain. In other words, it's your usual mix of technical people.
perl5-porters メーリングリストの購読者(「porters」自身)にもさまざまな種類の 人がいます。 何かを知るために黙って投稿を読んでいるだけの人もいますし(彼らは、 開発に加わることはめったにないものの、開発の進捗をウオッチして Perl の 最新の変更や機能を確実に先取りできるようにしているのです)、中にはベンダーを 代表して、Perl が自分たちのプラットフォームで確実にコンパイル、 動作できるようにし続けている人もいます。 直し方を知っているバグレポートが来たらパッチをあてるという人もいますし、 自分の好きな分野(スレッド、Win32、正規表現エンジン)には積極的に パッチをあてるという人もいます。 文句を言っているだけのように見える人もいます。 別の言い方をすれば、よくある技術者たちの集まりだということです。
Among these people are the core Perl team. These are trusted volunteers involved in the ongoing development of the Perl language and interpreter. They are not required to be language developers or committers.
その中には、コア Perl チームも含まれています。 これは Perl 言語とインタプリタの進行中の開発に関わる信頼できる ボランティアです。 彼らは言語開発者やコミッタである必要はありません。
Over this group of porters presides Larry Wall. He has the final word in what does and does not change in any of the Perl programming languages. These days, Larry spends most of his time on Raku, while Perl 5 is shepherded by a steering council of porters responsible for deciding what goes into each release and ensuring that releases happen on a regular basis.
この porters グループの頂点にいるのが Larry Wall です。 Larry は Perl というプログラミング言語のあらゆる部分について、変える、 変えないの最終決定権を持っています。 ただし、最近では Larry がほとんどの時間を Raku に費やしているため、 Perl 5 の方は porters の運営委員会が率いているようになっています。 パンプキンの仕事は、何をどのリリースに含めるかを決め、リリースが定期的に 行われるように手配することです。
Larry sees Perl development along the lines of the US government: there's the Legislature (the porters, represented by the core team), the Executive branch (the steering council), and the Supreme Court (Larry). The legislature can discuss and submit patches to the executive branch all they like, but the executive branch is free to veto them. Rarely, the Supreme Court will side with the executive branch over the legislature, or the legislature over the executive branch. Mostly, however, the legislature and the executive branch are supposed to get along and work out their differences without impeachment or court cases.
Larry は Perl の開発をアメリカの行政機構になぞらえています。 つまり、議会(コアチームに代表される porters)があり、政府(運営委員会)があり、 最高裁(Larry)があるというわけです。 議会は自分たちの好きなように議論し、パッチを政府に提出できますが、政府には そのパッチを拒否する自由があります。 最高裁はよほどのことでもなければ議会より政府を 優先する立場をとったり、政府より議会を優先する立場をとったりしませんが、 ふつうは議会も政府も、訴追や裁判に訴えることなく、協力して意見の相違を すりあわせるものとされています。
You might sometimes see reference to Rule 1 and Rule 2. Larry's power as Supreme Court is expressed in The Rules:
ただし、ときには「ルール 1」や「ルール 2」への言及を 目にすることがあるかもしれません。 最高裁としてのLarryの権力を示すものとして、以下のような「ルール」があります。
-
Larry is always by definition right about how Perl should behave. This means he has final veto power on the core functionality.
定義により、Perl がどう振る舞うべきかについては常に Larry が 正しいことになっています。 つまり、コア機能についてはLarryが最終的な拒否権を持っています。
-
Larry is allowed to change his mind about any matter at a later date, regardless of whether he previously invoked Rule 1.
Larry はいかなることについても、あとから考えを変えることが許されています。 以前にルール 1 を発動させたかどうかにかかわらずです。
Got that? Larry is always right, even when he was wrong. It's rare to see either Rule exercised, but they are often alluded to.
わかりましたね? Larry は常に正しいのです。 たとえ過去の彼が間違っていたとしても。 どちらのルールも実際に発動されることはめったにありませんが、 それとなく言われることはままあるものです。
For the specifics on how the members of the core team and steering council are elected or rotated, consult perlgov, which spells it all out in detail.
コアチームや運営委員会のメンバーがどのように選出、交代するかに関する 詳細については、全ての詳細について記述している perlgov を 参照してください。
メンテナンスとサポート¶
Perl 5 is developed by a community, not a corporate entity. Every change contributed to the Perl core is the result of a donation. Typically, these donations are contributions of code or time by individual members of our community. On occasion, these donations come in the form of corporate or organizational sponsorship of a particular individual or project.
Perl 5 の開発にあたっているのはコミュニティであり、企業体ではありません。 Perl コアに加えられる変更はすべからく寄付によるものです。 この寄付は、典型的にはコミュニティに属する個人がコードや時間を 提供するという形で行われていますが、場合によっては企業、団体が 特定個人ないしプロジェクトに出資するという形をとることもあります。
As a volunteer organization, the commitments we make are heavily dependent on the goodwill and hard work of individuals who have no obligation to contribute to Perl.
ボランティアの集団である私たちの活動は個人の厚意や努力に大きく依存しています。 私たちには Perl に貢献しなければならない義務があるわけではありません。
That being said, we value Perl's stability and security and have long had an unwritten covenant with the broader Perl community to support and maintain releases of Perl.
もっとも、私たちも Perl の安定性や安全性は大切に思っています。 そのため、昔から、より広い意味での Perl コミュニティに属するみなさんとの 暗黙の了解事項として、 過去にリリースされた Perl のサポートやメンテナンスもしてきました。
This document codifies the support and maintenance commitments that the Perl community should expect from Perl's developers:
この文書はそのサポートやメンテナンスの約束を成文化するためのものです。 Perl コミュニティが Perl の開発陣に期待してもよいものは以下の通りです。
-
We "officially" support the two most recent stable release series. 5.36.x and earlier are now out of support. As of the release of 5.42.0, we will "officially" end support for Perl 5.38.x, other than providing security updates as described below.
私たちが「公式に」サポートするのは、最新の安定版とそのひとつ前の 安定版のみです。 5.36.x 以前のバージョンはもうサポートの対象外です。 5.42.0 がリリースされたら「公式に」Perl 5.38.x のサポートを終了します。 ただし、後述するセキュリティアップデートの提供は例外とします。
-
To the best of our ability, we will attempt to fix critical issues in the two most recent stable 5.x release series. Fixes for the current release series take precedence over fixes for the previous release series.
直近二つの安定版については、最善を尽くして致命的な問題の修正につとめます。 また、現行版に対する修正は過去のリリースに対する修正より優先されます。
-
To the best of our ability, we will provide "critical" security patches / releases for any major version of Perl whose 5.x.0 release was within the past three years. We can only commit to providing these for the most recent .y release in any 5.x.y series.
過去 3 年以内にバージョン 5.x.0 がリリースされた Perl に対する「致命的な」 セキュリティ問題については、最善を尽くしてパッチやリリースを提供します。 ただし、提供を約束できるのはそれぞれの 5.x.y シリーズの 最新の .y リリースについてのみです。
-
We will not provide security updates or bug fixes for development releases of Perl.
開発版の Perl に対するセキュリティアップデートやバグ修正は行いません。
-
We encourage vendors to ship the most recent supported release of Perl at the time of their code freeze.
ベンダー各位にはベンダー各位のコードフリーズ時点でサポートされている 最新の Perl を同梱してくださるようお願いします。
-
As a vendor, you may have a requirement to backport security fixes beyond our 3 year support commitment. We can provide limited support and advice to you as you do so and, where possible will try to apply those patches to the relevant -maint branches in git, though we may or may not choose to make numbered releases or "official" patches available. See "SECURITY VULNERABILITY CONTACT INFORMATION" in perlsec for details on how to begin that process.
ベンダー各位には、Perl の開発陣が約束する 3 年間というサポート期間よりも古い バージョンにセキュリティフィックスをあてる必要があるかもしれません。 その場合、限定的なサポートや助言であれば提供できますし、 可能ならばそのようなパッチを関係する -maint ブランチにもあてる努力はします。 ただし、バージョンをあげてリリースをしたり「公式」パッチを提供する選択を 行うかどうかはわかりません。 この手続きの始め方に関する詳細については "SECURITY VULNERABILITY CONTACT INFORMATION" in perlsec を参照してください。
後方互換性と廃止予定¶
Our community has a long-held belief that backward-compatibility is a virtue, even when the functionality in question is a design flaw.
Perl コミュニティは昔から後方互換性を美徳としてきました。 たとえ問題の機能が設計上の欠陥だったとしてもです。
We would all love to unmake some mistakes we've made over the past decades. Living with every design error we've ever made can lead to painful stagnation. Unwinding our mistakes is very, very difficult. Doing so without actively harming our users is nearly impossible.
過去何十年かのうちにしでかした失敗のいくつかをなかったものにしたいとは 誰しも願うことです。 過去にしでかしたあらゆる設計ミスを甘受していては つらい停滞期にもつながりかねません。 ただし、失敗をなかったことにするのは 本当に本当にむずかしいことですし、わざわざユーザを傷つけるようなことを せずにすますのはほとんど不可能です。
Lately, ignoring or actively opposing compatibility with earlier versions of Perl has come into vogue. Sometimes, a change is proposed which wants to usurp syntax which previously had another meaning. Sometimes, a change wants to improve previously-crazy semantics.
最近は過去のバージョンとの互換性を無視したり、わざわざ互換性をなくすような 動きが流行しています。 以前は別の意味を持っていた文法を無理矢理別の意味で使うような 変更が提案されることもありますし、以前のとんでもない動作を 改善しようとする変更もあります。
Down this road lies madness.
この道の先にあるのは、狂気です。
Requiring end-user programmers to change just a few language constructs, even language constructs which no well-educated developer would ever intentionally use is tantamount to saying "you should not upgrade to a new release of Perl unless you have 100% test coverage and can do a full manual audit of your codebase." If we were to have tools capable of reliably upgrading Perl source code from one version of Perl to another, this concern could be significantly mitigated.
エンドユーザのプログラマに多少であっても言語の構築要素を変更するよう 強制するのは、たとえそれが十分な教育を受けた開発者ならわざわざ 使ったりはしないような要素であってもひどいことですし、 「コードベースのテストカバレッジ率が 100% で、十分な手動チェックを 行えるのでもなければ、Perl を最新版にアップグレードすべきではない」と 言うようなものです。 特定バージョンの Perl から別のバージョンの Perl へと確実にソースコードを アップグレードできるツールでもあればこの懸念はかなり緩和されるでしょうが、 そのようなものはまだありません。
We want to ensure that Perl continues to grow and flourish in the coming years and decades, but not at the expense of our user community.
私たちはこの先何年、何十年と Perl が成長、繁栄し続けるようにしたいと 思っていますが、 そのためにユーザコミュニティを犠牲にするようなことはしたくありません。
Existing syntax and semantics should only be marked for destruction in very limited circumstances. If they are believed to be very rarely used, stand in the way of actual improvement to the Perl language or perl interpreter, and if affected code can be easily updated to continue working, they may be considered for removal. When in doubt, caution dictates that we will favor backward compatibility. When a feature is deprecated, a statement of reasoning describing the decision process will be posted, and a link to it will be provided in the relevant perldelta documents.
既存の文法や動作を破壊するのはごく限られた場合のみで あるべきです。 ある機能がほとんど使われていないと信じることができ、 Perl 言語や perl インタプリタの実際の改良の邪魔になり、 影響を受けるコードが動き続けるように簡単に更新できる場合、 削除が考慮されることがあります。 疑わしい場合は、後方互換性を重視しているので、用心が上回ります。 ある機能が廃止予定になるとき、決定手順を説明した理由の声明が投稿され、 関連する perldelta でそれへのリンクが提供されます。
Using a lexical pragma to enable or disable legacy behavior should be considered when appropriate, and in the absence of any pragma legacy behavior should be enabled. Which backward-incompatible changes are controlled implicitly by a 'use v5.x.y' is a decision which should be made by the steering council in consultation with the community.
適切な場合は、以前の振る舞いを有効または無効にするためのレキシカルプラグマが 考慮されるべきです; そしてプラグマがない場合は以前の振る舞いが 有効になるべきです。 また、後方非互換な変更のうち、 'use v5.x.y' によって暗黙のうちに管理されるものをどれにするかは運営委員会が コミュニティと相談して決めるべきことです。
Historically, we've held ourselves to a far higher standard than backward-compatibility -- bugward-compatibility. Any accident of implementation or unintentional side-effect of running some bit of code has been considered to be a feature of the language to be defended with the same zeal as any other feature or functionality. No matter how frustrating these unintentional features may be to us as we continue to improve Perl, these unintentional features often deserve our protection. It is very important that existing software written in Perl continue to work correctly. If end-user developers have adopted a bug as a feature, we need to treat it as such.
歴史的には、私たちは後方互換性よりもはるかに高い基準――後方バグ互換性――を 守ってきました。 実装上のどんな事故も、コードの小片を実行したときの意図せぬ 副作用も、言語の一機能として、ほかのあらゆる機能と同じ熱意を持って守るべき ものとみなしてきたのです。 このような意図せぬ機能がPerlの改善を続けていく うちにどんなにいらだたしいものになったとしても、多くの場合は残しておくだけの 価値はあります。 Perl で書かれた既存のソフトウェアが正しく動作し続けることは 非常に大切なことであり、エンドユーザ側の開発者がバグを一機能として認めて しまったのであれば、私たちもそれをそのように扱う必要があるのです。
New syntax and semantics which don't break existing language constructs and syntax have a much lower bar. They merely need to prove themselves to be useful, elegant, well designed, and well tested. In most cases, these additions will be marked as experimental for some time. See below for more on that.
新しい文法や動作であっても、既存の言語要素や文法を 破壊しないものについてははるかに障壁が低くなります。 役に立ち、エレガントで、 しっかり設計され、よくテストされていることを証明しさえすればよいのです。 ほとんどの場合、これらの追加はしばらくの間 実験的 (experimental) として 銘打たれます。 これに関するさらなる情報は以下を参照してください。
用語¶
To make sure we're talking about the same thing when we discuss the removal of features or functionality from the Perl core, we have specific definitions for a few words and phrases.
Perl のコアから機能を削除する話をする際の認識あわせを確実にするため、 特定の意味で使っている語句がいくつかあります。
- experimental
-
(実験的(experimental))
If something in the Perl core is marked as experimental, we may change its behaviour, deprecate or remove it without notice. While we'll always do our best to smooth the transition path for users of experimental features, you should contact the perl5-porters mailinglist if you find an experimental feature useful and want to help shape its future.
Perl コアに入っているもので実験的(experimental)と銘打たれている ものについては、 予告なく動作を変更したり、廃止予定にしたり、削除したりすることがあります。 実験的な機能を 使っているユーザがスムーズに移行できるよういつでも最大限の努力はしますが、 もし何らかの実験的な機能について便利なので将来的にも残したいと思ったら perl5-porters メーリングリストに投稿してください。
Experimental features must be experimental in two stable releases before being marked non-experimental. Experimental features will only have their experimental status revoked when they no longer have any design-changing bugs open against them and when they have remained unchanged in behavior for the entire length of a development cycle. In other words, a feature present in v5.20.0 may be marked no longer experimental in v5.22.0 if and only if its behavior is unchanged throughout all of v5.21.
実験的機能は、実験的でないとされる前に、二つの安定版リリースの間 実験的でなければなりません。 実験的機能は、もはや設計を変更するようなバグがなく、一つの開発サイクルの間 振る舞いが変更されなかった場合にのみ、その実験的という状態が削除されます。 言い換えると、v5.20.0 に存在する機能は、全ての v5.21 の間にその振る舞いが 変わらなかった場合にのみ、v5.22.0 で実験的でなくなります。
- deprecated
-
(廃止予定(deprecated))
If something in the Perl core is marked as deprecated, we may remove it from the core in the future, though we might not. Generally, backward incompatible changes will have deprecation warnings for two release cycles before being removed, but may be removed after just one cycle if the risk seems quite low or the benefits quite high.
Perl コアに入っているもので廃止予定(deprecated)と銘打たれているものに ついては、将来コアから削除するかもしれません(しないかもしれません)。 一般的に、後方互換性を失う変更は、削除される前に二つのリリースサイクルの間 廃止予定警告を出しますが、リスクが非常に低いか効果が非常に高い場合は、 一つのサイクルの後で削除されることがあります。
As of Perl 5.12, deprecated features and modules warn the user as they're used. When a module is deprecated, it will also be made available on CPAN. Installing it from CPAN will silence deprecation warnings for that module.
Perl 5.12 以降、 廃止予定の機能やモジュールを使った場合は警告が出るようになりました。 モジュールを廃止予定にする場合、 そのモジュールは CPAN から入手できるようにします。 CPAN からモジュールをインストールすると そのモジュールについての廃止予定の警告は出なくなります。
If you use a deprecated feature or module and believe that its removal from the Perl core would be a mistake, please contact the perl5-porters mailinglist and plead your case. We don't deprecate things without a good reason, but sometimes there's a counterargument we haven't considered. Historically, we did not distinguish between "deprecated" and "discouraged" features.
廃止予定の機能やモジュールを使っていて、Perl コアから削除してしまうのは 間違いだと思う方は perl5-porters のメーリングリストに投稿してください。 私たちは十分な理由がなければ廃止予定にはしませんが、 私たちが考慮しなかった反論が出てくる場合もあります。 歴史的には「廃止予定(deprecated)」の機能と 「非推奨(discouraged)」の機能の区別はありませんでした。
- discouraged
-
(非推奨(discouraged))
From time to time, we may mark language constructs and features which we consider to have been mistakes as discouraged. Discouraged features aren't currently candidates for removal, but we may later deprecate them if they're found to stand in the way of a significant improvement to the Perl core.
私たちはときどき失敗だったと思われる言語要素や機能を 非推奨(discouraged) と 銘打つことがあります。 非推奨の機能は現在の所削除対象にはなりませんが、 その後、Perl コアを大きく改善しようとする際に障害となることが判明した場合は 廃止予定にすることはあります。
- removed
-
(削除(removed))
Once a feature, construct or module has been marked as deprecated, we may remove it from the Perl core. Unsurprisingly, we say we've removed these things. When a module is removed, it will no longer ship with Perl, but will continue to be available on CPAN.
安定版リリースの際に一度廃止予定と銘打たれた機能や言語要素、モジュールに ついては、Perl コアから削除することがあります。 当然ながら、そのようなものについては 削除(removed) したと言います。 モジュールを削除した場合、そのモジュールは以後 Perl に同梱されることはなくなりますが、CPAN からは引き続き入手できます。
メンテナンスブランチ¶
New releases of maintenance branches should only contain changes that fall into one of the "acceptable" categories set out below, but must not contain any changes that fall into one of the "unacceptable" categories. (For example, a fix for a crashing bug must not be included if it breaks binary compatibility.)
メンテナンスブランチの新しいリリースは、後述する「受け入れられる」カテゴリの 一つである変更のみを含むべきで、「受け入れられない」カテゴリのものは 含めてはいけません。 (例えば、クラッシュバグの修正は、バイナリ互換性を破壊する場合は含めては いけません。)
It is not necessary to include every change meeting these criteria, and in general the focus should be on addressing security issues, crashing bugs, regressions and serious installation issues. The temptation to include a plethora of minor changes that don't affect the installation or execution of perl (e.g. spelling corrections in documentation) should be resisted in order to reduce the overall risk of overlooking something. The intention is to create maintenance releases which are both worthwhile and which users can have full confidence in the stability of. (A secondary concern is to avoid burning out the maint-release manager or overwhelming other committers voting on changes to be included (see "Getting changes into a maint branch" below).)
この基準に適合する全ての変更を含む必要はなく、一般的には セキュリティ問題、クラッシュバグ、退行、重大なインストール問題に 集中するべきです。 perl のインストールに影響を与えない大量の小さな変更 (文書のスペル修正など) を含めるという誘惑に対しては、 何かを見落とす全体的なリスクを減らすために抵抗されるべきです。 この目的は、価値があり、ユーザーが安定性に完全な自信を持てる メンテナンスリリースを作ることです。 (補助的な考慮事項は、メンテナンスリリースマネージャの燃え尽きを避けたり、 どの変更を含むかを投票するその他のコミッタが圧倒されることを避けることです (後述する "Getting changes into a maint branch" を参照してください)。)
The following types of change may be considered acceptable, as long as they do not also fall into any of the "unacceptable" categories set out below:
次のような変更は、その次にある「受け入れられない」カテゴリのものでなければ、 受け入れられると考えられます。
-
Patches that fix CVEs or security issues. These changes should be passed using the security reporting mechanism rather than applied directly; see "SECURITY VULNERABILITY CONTACT INFORMATION" in perlsec.
CVE やセキュリティの問題を修正するパッチ。 これらの変更は、パッチを直接適用するのではなく、 セキュリティ報告機構を使って渡されたものであるべきです; "SECURITY VULNERABILITY CONTACT INFORMATION" in perlsec を参照してください。
-
Patches that fix crashing bugs, assertion failures and memory corruption but which do not otherwise change perl's functionality or negatively impact performance.
クラッシュするバグ、アサーション失敗、メモリ破壊を修正するパッチで、 ほかの機能を変更せず、性能を劣化させないもの。
-
Patches that fix regressions in perl's behavior relative to previous releases, no matter how old the regression, since some people may upgrade from very old versions of perl to the latest version.
過去のリリースに比べて Perl の挙動が退行した場合、それを修正するパッチ; どれだけ古い退行であってもです; とても古いバージョンの perl から最新バージョンにアップグレードする人が いるかもしれないからです。
-
Patches that fix bugs in features that were new in the corresponding 5.x.0 stable release.
対応する 5.x.0 安定版リリースでの新機能のバグを修正するパッチ。
-
Patches that fix anything which prevents or seriously impacts the build or installation of perl.
perl のビルドやインストールを阻害したり重大な影響を与えたりするものを 修正するパッチ。
-
Portability fixes, such as changes to Configure and the files in the hints/ folder.
Configure や hints ディレクトリ内のファイルに対する修正など、移植性の問題 に対する修正。
-
Minimal patches that fix platform-specific test failures.
特定のプラットフォームに固有のテストの失敗を修正する最小限のパッチ。
-
Documentation updates that correct factual errors, explain significant bugs or deficiencies in the current implementation, or fix broken markup.
事実関係の誤りを正す、現在の実装の重大なバグや欠陥を説明する、 マークアップの崩れを訂正する、といった文書の更新。
-
Updates to dual-life modules should consist of minimal patches to fix crashing bugs or security issues (as above). Any changes made to dual-life modules for which CPAN is canonical should be coordinated with the upstream author.
二重管理モジュールの更新については、(上述の通り)クラッシュバグの修正や セキュリティ問題の修正を行う最小限のパッチのみ含むようにすべきです。 CPAN 版が正とされる二重管理モジュールに対する変更は、 上流の作者と調整しながら行うべきです。
The following types of change are NOT acceptable:
次のような種類の変更は受け入れられません:
-
Patches that break binary compatibility. (Please talk to the steering council.)
バイナリ互換性を破壊するパッチ。 (運営委員会に相談してください。)
-
Patches that add or remove features.
機能を追加、削除するパッチ。
-
Patches that add new warnings or errors or deprecate features.
新しい警告やエラーを追加したり、機能を廃止予定にするパッチ。
-
Ports of Perl to a new platform, architecture or OS release that involve changes to the implementation.
実装の変更を伴う、新しいプラットフォーム、アーキテクチャ、OS への Perl の移植。
-
New versions of dual-life modules should NOT be imported into maint. Those belong in the next stable series.
二重管理モジュールの新版はメンテナンスブランチにインポートすべきでは ありません。 二重管理モジュールの新版は次の安定版に属するものです。
If there is any question about whether a given patch might merit inclusion in a maint release, then it almost certainly should not be included.
メンテナンスリリースに含める価値があるか疑問が残るパッチについては、ほぼ 確実に含めるべきではありません。
maint ブランチに変更を加える¶
Historically, only the single-person project manager cherry-picked changes from bleadperl into maintperl. This has scaling problems. At the same time, maintenance branches of stable versions of Perl need to be treated with great care. To that end, as of Perl 5.12, we have a new process for maint branches.
歴史的に、bleadperl から maintperl へ更新のチェリーピッキングを行っていたのは 一人のプロジェクトマネージャだけでした。 これは、スケールしないという問題があります。 また、安定版のメンテナンスブランチは細心の注意を払って取り扱う必要もあります。 そのため、Perl 5.12 以降、maint ブランチについては新しいやり方をとっています。
Any committer may cherry-pick any commit from blead to a maint branch by first adding an entry to the relevant voting file in the maint-votes branch announcing the commit as a candidate for back-porting, and then waiting for at least two other committers to add their votes in support of this (i.e. a total of at least three votes is required before a commit may be back-ported).
blead から maint ブランチには、コミッタなら誰でも、どのコミットでも チェリーピッキングできます; まず、バックポート候補のコミットを通知する maint-votes ブランチにある 適切な投票ファイルにエントリを追加し、 それから、それを支持する投票を追加する少なくとも二人の他のコミッタを 待ちます (つまり、コミットがバックポートされる前には、少なくとも 合計 3 票が必要です)。
Most of the work involved in both rounding up a suitable set of candidate commits and cherry-picking those for which three votes have been cast will be done by the maint branch release manager, but anyone else is free to add other proposals if they're keen to ensure certain fixes don't get overlooked or fear they already have been.
適切なコミット候補の集合をまとめて、3 票以上投じられたものを チェリーピックすることに関する作業のほとんどは、 メンテナンスブランチリリースマネージャによって行われますが、 他の誰でも、特定の修正が見落としていなかったり既にしている恐れがないことが 確実な場合は、自由に他の提案を追加できます。
Other voting mechanisms may also be used instead (e.g. sending mail to perl5-porters and at least two other committers responding to the list giving their assent), as long as the same number of votes is gathered in a transparent manner. Specifically, proposals of which changes to cherry-pick must be visible to everyone on perl5-porters so that the views of everyone interested may be heard.
透明性のある手段によって、同じ数の得票を集められれば、代わりに他の投票機構を 使うこともできます (例えば perl5-porters にメールを送って、少なくとも他の2人のコミッタが 賛意をリストに送る)。 特に、どの変更をチェリーピックするかの提案は、 関心のある人全ての耳に届くように、 perl5-porters の全員から見える形でなければなりません。
It is not necessary for voting to be held on cherry-picking perldelta entries associated with changes that have already been cherry-picked, nor for the maint-release manager to obtain votes on changes required by the Porting/release_managers_guide.pod where such changes can be applied by the means of cherry-picking from blead.
既にチェリーピッキングされている変更に関する perldelta エントリを チェリーピッキングする場合や、メンテナンスリリースマネージャが Porting/release_managers_guide.pod で求められている変更をする場合は、 投票する必要はありません; これらの変更は blead からチェリーピッキングされる場合が適用されます。
寄贈されたモジュール¶
アーティスティックコントロールに関する社会契約¶
What follows is a statement about artistic control, defined as the ability of authors of packages to guide the future of their code and maintain control over their work. It is a recognition that authors should have control over their work, and that it is a responsibility of the rest of the Perl community to ensure that they retain this control. It is an attempt to document the standards to which we, as Perl developers, intend to hold ourselves. It is an attempt to write down rough guidelines about the respect we owe each other as Perl developers.
以下はアーティスティックコントロールについての声明です; アーティスティックコントロールは パッケージの作者がそのコードの命運を握り、作品の管理権を維持できるように することと定義されます。 これは、作品を管理するのは作者であるべきであり、Perl コミュニティに 属する人々には、作者がその管理権を確実に保持できるようにする責任がある、と 認めるものです。 Perl 開発者が遵守すべき規範を文書化しようという試みであり、Perl 開発者同士 尊重しあおうという大まかなガイドラインを書き下ろす試みでもあります。
This statement is not a legal contract. This statement is not a legal document in any way, shape, or form. Perl is distributed under the GNU Public License and under the Artistic License; those are the precise legal terms. This statement isn't about the law or licenses. It's about community, mutual respect, trust, and good-faith cooperation.
この声明は法的な契約ではありません。 この声明はいかなる意味、形式でも法律文書ではありません。 Perl は GNU Public License と Artistic License のもとで配布されています; これこそが法律用語です。 この声明は法律やライセンスに関するものではありません。 この声明はコミュニティや相互尊重、信頼、誠実な協力についてのものです。
We recognize that the Perl core, defined as the software distributed with the heart of Perl itself, is a joint project on the part of all of us. From time to time, a script, module, or set of modules (hereafter referred to simply as a "module") will prove so widely useful and/or so integral to the correct functioning of Perl itself that it should be distributed with the Perl core. This should never be done without the author's explicit consent, and a clear recognition on all parts that this means the module is being distributed under the same terms as Perl itself. A module author should realize that inclusion of a module into the Perl core will necessarily mean some loss of control over it, since changes may occasionally have to be made on short notice or for consistency with the rest of Perl.
私たちは、Perl コア(Perl 自身の本体として配布されているソフトウェアと 定義されます)は 私たち全員が関与しているジョイントプロジェクトであると認識しています。 ときどき、あるスクリプトなりモジュールなりモジュール群なり(以降は単に 「モジュール」と呼称します)が 非常に便利である、あるいは Perl 自身の正しい動作に不可欠であると実証されて、 Perl コアとともに配布すべきだとされることもありますが、 そのモジュールの作者が明示的に同意し、 そのモジュールが Perl 自身と同じライセンスで配布されることになることも明確に 認識していない限り、そのようなことはすべきではありません。 モジュールの作者は、モジュールを Perl のコアに含めることで必然的に 支配権の一部を失うことになることは理解すべきです; ときには、急な通告とともに、あるいは Perl のほかの部分と一貫性を保つために、 変更が加えられることもありうるためです。
Once a module has been included in the Perl core, however, everyone involved in maintaining Perl should be aware that the module is still the property of the original author unless the original author explicitly gives up their ownership of it. In particular:
ただし、モジュールが Perl コアに入ったからといって、原作者が明示的に所有権を 放棄しない限り、そのモジュールはまだ原作者の所有物である、ということを、 Perl のメンテナンスに関わっている人は皆、頭に入れておくべきです。 具体的に言うと:
-
The version of the module in the Perl core should still be considered the work of the original author. All patches, bug reports, and so forth should be fed back to them. Their development directions should be respected whenever possible.
Perl コアに入っているバージョンもまだ原作者の作品であるとみなすべきであり、 パッチやバグレポートなどはすべて原作者にフィードバックすべきです。 原作者の開発方針は可能な限り尊重されるべきです。
-
Patches may be applied by the steering council without the explicit cooperation of the module author if and only if they are very minor, time-critical in some fashion (such as urgent security fixes), or if the module author cannot be reached. Those patches must still be given back to the author when possible, and if the author decides on an alternate fix in their version, that fix should be strongly preferred unless there is a serious problem with it. Any changes not endorsed by the author should be marked as such, and the contributor of the change acknowledged.
運営委員会がモジュール作者の明示的な協力なしにパッチを適用してもよいのは、 そのパッチが非常に小さなもので、（緊急のセキュリティパッチなど） 何らかの事情で最優先で処理する必要がある場合、あるいはモジュール作者と 連絡がつかない場合のみです。 このような場合も、パッチは可能ならばかならず作者に還元しなければなりません。 また、作者が自分のバージョンで別のやり方で修正を加える決断をした場合、 その修正に深刻な問題がない限り、作者側の修正を積極的に優先すべきです。 作者の承認を得ていない変更はすべからくそのように銘打つべきですし、 その変更に貢献した人を明記すべきです。
-
The version of the module distributed with Perl should, whenever possible, be the latest version of the module as distributed by the author (the latest non-beta version in the case of public Perl releases), although the steering council may hold off on upgrading the version of the module distributed with Perl to the latest version until the latest version has had sufficient testing.
Perl に同梱されているバージョンは、可能ならば常に原作者が配布している モジュールの最新版(Perl の公開版の場合は最新の非ベータ版)であるべきです。 ただし、最新版が十分にテストされるまで運営委員会が Perl に同梱されている モジュールのアップグレードを先送りにすることはあります。
In other words, the author of a module should be considered to have final say on modifications to their module whenever possible (bearing in mind that it's expected that everyone involved will work together and arrive at reasonable compromises when there are disagreements).
言い換えると、モジュールの修正に対する最終決定権は可能な限り常にモジュールの 作者が持っているとみなすべきです(ただし、意見の相違がある場合、関係者全員が 協力して合理的な妥協を行うことが期待されていることは 念頭に入れておいてください)。
As a last resort, however:
ただし、最後の手段として:
If the author's vision of the future of their module is sufficiently different from the vision of the steering council and perl5-porters as a whole so as to cause serious problems for Perl, the steering council may choose to formally fork the version of the module in the Perl core from the one maintained by the author. This should not be done lightly and should always if at all possible be done only after direct input from Larry. If this is done, it must then be made explicit in the module as distributed with the Perl core that it is a forked version and that while it is based on the original author's work, it is no longer maintained by them. This must be noted in both the documentation and in the comments in the source of the module.
作者がそのモジュールを将来どうしたいかという展望と、運営委員会や perl5-porters 全体の展望とが著しく異なり、Perl に深刻な問題を引き起こす場合、 運営委員会は、作者がメンテナンスしているバージョンから Perl コアに入れる バージョンを公式に枝分かれさせる選択をすることもあります。 この選択は軽々しく行うべきではありませんし、可能な限り かならず Larry に 直接指示をあおいだうえで行うべきです。 また、そうしてしまった場合は、Perl コアに同梱するモジュールには、もとの モジュールから分岐したバージョンであること、また原作者の作品に 基づいているものの、もう原作者がメンテナンスしているわけではないことを 明記しなければなりません。 これは文書だけでなく、モジュールのソースコードにもコメントとして 記載しなければなりません。
Again, this should be a last resort only. Ideally, this should never happen, and every possible effort at cooperation and compromise should be made before doing this. If it does prove necessary to fork a module for the overall health of Perl, proper credit must be given to the original author in perpetuity and the decision should be constantly re-evaluated to see if a remerging of the two branches is possible down the road.
繰り返しますが、これは最後の手段としてのみ使うべきです。 理想的にはこのようなことは決して起こるべきではありませんし、 こうなる前にあらゆる努力を払って協力、妥協すべきです。 Perl 全体の健全性を保つためにはどうしてもモジュールをフォークする 必要があると証明された場合も、原作者に対する適切なクレジット表示は永遠に残して おかなければなりませんし、その決断が正しかったかを定期的に再評価し、将来的に 二つのブランチをマージしなおすことができるか確認すべきです。
In all dealings with contributed modules, everyone maintaining Perl should keep in mind that the code belongs to the original author, that they may not be on perl5-porters at any given time, and that a patch is not official unless it has been integrated into the author's copy of the module. To aid with this, and with points #1, #2, and #3 above, contact information for the authors of all contributed modules should be kept with the Perl distribution.
提供されたモジュールの扱いについて、Perl をメンテナンスするすべての人が 念頭に入れておくべきことは、そのコードは原作者に属するものであり、 いついかなるときも perl5-porters のものではないこと、パッチは作者側の モジュールに取り込まれるまで公式のものとはみなされないことです。 そのためにも、また上記 #1、#2、#3 のためにも、提供されたすべての モジュールの作者の連絡先を Perl のディストリビューション内に 保存しておくべきです。
Finally, the Perl community as a whole recognizes that respect for ownership of code, respect for artistic control, proper credit, and active effort to prevent unintentional code skew or communication gaps is vital to the health of the community and Perl itself. Members of a community should not normally have to resort to rules and laws to deal with each other, and this document, although it contains rules so as to be clear, is about an attitude and general approach. The first step in any dispute should be open communication, respect for opposing views, and an attempt at a compromise. In nearly every circumstance nothing more will be necessary, and certainly no more drastic measure should be used until every avenue of communication and discussion has failed.
最後になりますが、Perl コミュニティは、全体としては、コードの所有権を 尊重することや、アーティスティックコントロールを尊重すること、適切な クレジット表示、意図せぬひずみやコミュニケーションギャップを防ぐ積極的な 努力をすることがコミュニティと Perl 自身の 健全性を保つ重要な鍵であることを認識していますし、コミュニティのメンバーも、 ふつうはルールや法律に訴えずともお互いに付き合っていけるはずです。 意図を明確にするためにルールが書いてありますが、この文書自体、 姿勢や一般的なアプローチについてのものです。 論争解決の第一歩はオープンなコミュニケーションであり、対立する視点に対する 敬意であり、妥協の試みであるべきです。 ほとんどどんな場合でもそれ以上のものは必要ないでしょうし、あらゆる コミュニケーションや議論が失敗に終わるまで、それ以上の思い切った手段は とるべきではありません。
文書¶
Perl's documentation is an important resource for our users. It's incredibly important for Perl's documentation to be reasonably coherent and to accurately reflect the current implementation.
Perl の文書はユーザにとって重要なリソースであり、無理のない範囲で 首尾一貫していることや、現在の実装を正確に反映していることは本当に 大切なことです。
Just as P5P collectively maintains the codebase, we collectively maintain the documentation. Writing a particular bit of documentation doesn't give an author control of the future of that documentation. At the same time, just as source code changes should match the style of their surrounding blocks, so should documentation changes.
P5P が共同でコードベースをメンテナンスしているのと同様に、私たちは文書の メンテナンスも共同で行っています。 文書の特定の一部を執筆したからといって、 著者としてその文書の将来を管理する権利が与えられるわけではありません。 また、ソースコードを変更するときは周辺ブロックのスタイルに あわせるべきであるのと 同様に、文書を変更するときも周辺文書のスタイルにあわせるべきです。
Examples in documentation should be illustrative of the concept they're explaining. Sometimes, the best way to show how a language feature works is with a small program the reader can run without modification. More often, examples will consist of a snippet of code containing only the "important" bits. The definition of "important" varies from snippet to snippet. Sometimes it's important to declare use strict and use warnings, initialize all variables and fully catch every error condition. More often than not, though, those things obscure the lesson the example was intended to teach.
文書中の例は、そこで説明している概念を例証するものであるべきです。 言語機能の働きを示す最適なやり方として、読者が何の修正もなく実行できる小さな プログラムを用いる場合もありますが、それよりも、「重要な」部分のみを含む コード片を例とする方が多いです。 何がどう「重要」かはコード片によって異なります。 use strict や use warnings を宣言し、すべての変数を初期化して、 あらゆる例外を完璧に捕捉することが重要な場合もありますが、たいていの場合、 これらは例示しようとしているレッスンの内容をわかりにくくしてしまいます。
As Perl is developed by a global team of volunteers, our documentation often contains spellings which look funny to somebody. Choice of American/British/Other spellings is left as an exercise for the author of each bit of documentation. When patching documentation, try to emulate the documentation around you, rather than changing the existing prose.
Perl はグローバルなボランティアチームによって開発されているため、私たちの 文書には 誰かにとっては おかしく見えるスペルが含まれていることも 多々ありますが、アメリカ式/イギリス式/その他の綴り方の選択はその文書の 著者に任されています。 文書にパッチをあてる際には、既存の書き方を改めるのではなく、 周囲の文書のやり方にあわせるようにしてください。
In general, documentation should describe what Perl does "now" rather than what it used to do. It's perfectly reasonable to include notes in documentation about how behaviour has changed from previous releases, but, with very few exceptions, documentation isn't "dual-life" -- it doesn't need to fully describe how all old versions used to work.
一般論として、文書には Perl が昔どう動作したかではなく、「今」どう動作するか 書くべきです。 注意書きとして、過去のリリースからどう動作が変わったかを書くのは 完全に合理的なことですが、ごく一部の例外を除いて、文書は「二重管理」 ではありませんので、過去のすべてのバージョンについてどう動いていたかを 詳細に記述する必要はありません。
行動規範¶
The official forum for the development of perl is the perl5-porters mailing list, mentioned above, and its bugtracker at GitHub. Posting to the list and the bugtracker is not a right: all participants in discussion are expected to adhere to a standard of conduct.
perl の開発のための公式フォーラムは、前述の通り、 perl5-porters メーリングリストと、GitHub にあるバグトラッカーです。 リストとバグトラッカーへの投稿は権利ではありません。 議論に参加する全ての人は行動規範を遵守することが期待されています。
-
Always be civil.
いつも礼儀正しく。
-
Heed the moderators.
モデレータに注意を傾ける。
Civility is simple: stick to the facts while avoiding demeaning remarks, belittling other individuals, sarcasm, or a presumption of bad faith. It is not enough to be factual. You must also be civil. Responding in kind to incivility is not acceptable. If you relay otherwise-unposted comments to the list from a third party, you take responsibility for the content of those comments, and you must therefore ensure that they are civil.
礼儀正しさは単純です: 事実を基にし、品位を下げる発言、他の人をけなすこと、 皮肉、邪推はやめましょう。 事実に基づくだけでは十分ではありません。 礼儀正しくもなければなりません。 無作法に対して同じように対応することは受け入れられません。 あなたが第三者からのリストに投稿されていないコメントを転送する場合、 あなたはそのコメントの内容について責任があるので、 それが礼儀正しいことを保証しなければなりません。
While civility is required, kindness is encouraged; if you have any doubt about whether you are being civil, simply ask yourself, "Am I being kind?" and aspire to that.
礼儀正しさは要求されますが、親切さは推奨されます; 自分が礼儀正しいか 少しでも疑問に思ったら、単に自分に問いかけましょう; 「私は親切だろうか?」 そしてそれを目指しましょう。
If the list moderators tell you that you are not being civil, carefully consider how your words have appeared before responding in any way. Were they kind? You may protest, but repeated protest in the face of a repeatedly reaffirmed decision is not acceptable. Repeatedly protesting about the moderators' decisions regarding a third party is also unacceptable, as is continuing to initiate off-list contact with the moderators about their decisions.
もしリストのモデレータがあなたに礼儀正しくないと伝えた場合、 どのような形でも対応する前に、あなたの言葉がどのように現れたかを 慎重に考えてみてください。 それは親切でしたか? 抗議することはできますが、繰り返し再確認された決定に直面して 抗議を繰り返すことは受け入れられません。 また、第三者に関するモデレータの決定について繰り返し抗議することも、 その決定についてモデレータにリスト外で連絡を取ることも受け入れられません。
Unacceptable behavior will result in a public and clearly identified warning. A second instance of unacceptable behavior from the same individual will result in removal from the mailing list and GitHub issue tracker, for a period of one calendar month. The rationale for this is to provide an opportunity for the person to change the way they act.
受け入れられない振る舞いに対しては、公の場で明確に識別できる警告が 行われます。 同じ個人からの 2 回目の受け入れられない振る舞いがあった場合は、 メーリングリストと GitHub のイシュートラッカーから除去されます; 期間は 1 暦月です。 この理由は、その個人に行動方法を変える機会を与えるためです。
After the time-limited ban has been lifted, a third instance of unacceptable behavior will result in a further public warning. A fourth or subsequent instance will result in an indefinite ban. The rationale is that, in the face of an apparent refusal to change behavior, we must protect other community members from future unacceptable actions. The moderators may choose to lift an indefinite ban if the person in question affirms they will not transgress again.
時間制限除去が解除された後、3 回目の受け入れられない振る舞いについては 更なる公の場での警告が行われます。 4 回目以上の場合は無期限の除去となります。 理由は、振る舞いを変えることに対する明らかな拒否に直面した場合、 私たちは将来の受け入れられない行動からその他のコミュニティメンバーを 守らなければならないからです。 問題の人物が再び規則を破らないことを確約した場合は、 モデレータは無期限の除去の解除を選択できます。
Removals, like warnings, are public.
除去は、警告と同様、公の場で行われます。
The list of moderators will be public knowledge. At present, it is: Karen Etheridge, Neil Bowers, Nicholas Clark, Ricardo Signes, Todd Rinaldo.
モデレータの一覧は公開情報です。 現在の所は: Karen Etheridge, Neil Bowers, Nicholas Clark, Ricardo Signes, Todd Rinaldo.
CREDITS¶
"Social Contract about Contributed Modules" originally by Russ Allbery <rra@stanford.edu> and the perl5-porters.
"Social Contract about Contributed Modules" originally by Russ Allbery <rra@stanford.edu> and the perl5-porters.