パスワードを忘れた? アカウント作成
450246 journal

heberekeの日記: PFC RFC -PEAR Foundation Class RFC

日記 by hebereke
晒してみるテスト

原文
"http://marc.theaimsgroup.com/?l=pear-dev&m=104617534710384&w=2
--
[prev in list] [next in list] [prev in thread] [next in thread]

List:     pear-dev
Subject:  [PEAR-DEV] PFC-RFC Update
From:     Christian Stocker <chregu () bitflux ! ch>
Date:     2003-02-25 12:15:42
[Download message RAW]

Hi

I rewrote and extended it with all the comments I got. So here it is:

*******************************
* PEAR Foundation Classes RFC *
*******************************

Goal:

The intention of PEAR Foundation Classes is to provide well-written,
well-documentated, well-tested and well-extendable code within PEAR and
mark them as such. For becoming a PFC, a class has to follow strict rules.
Users of PFCs can be assured that those class went through thorough
reviewing and testing and therefore should be the first choice for
everyone needing a class for a given task.

目標

PEAR 基底クラス (以下 PFC) は PEAR に於いて優れた コード, ドキュメンテーション, テスティング, 拡張性 を提供し, またそれらの見本となるべく記述されている.
PEAR の各クラス (以下 PFCs) は PFC に則り, 以下に示す絶対のルールに従う必要がある.
利用者は PEAR のいずれのクラスもテストとレビューをパスしているものと思って利用できる. また故に PEAR 各クラスこそがそれぞれの目的に対する最良の選択となり得る.

Prerequesites:
--------------

必要条件

- PFCs should only depend on PFCs. If a needed library is not yet a PFC,
the developers should take the appropriate steps to make it a PFC, as
well.

PFC は PFC 以外に依存するクラスがあってはならない.
利用に際して PFC 以外のライブラリを必要とする場合, 開発者はそのライブラリも PFC にすること.

- PFCs should preferably have 2 lead-developer or at least some active and
dedictated  maintainers.

出来ればプロジェクトをリードできる開発者が二人いること.
少なくとも幾人かの活発にコミットを行うユーザーか献身的なメンテナがいること.

- PFCs have to strictly follow the PEAR Coding Standards

PFCs は 標準コーディング規約に厳密に従うこと.
(cf: http://pear.php.net/manual/ja/standards.php)

- PFCs have to provide scripts for unit testing

ユニットテストのためのスクリプトを用意すること.

- PFCs have to have thoroughly documented. This applies to inline docs
(PHPDoc), as well as external documentation (peardoc)

外部ドキュメント (peardoc) だけでなくソースコードでも PHPDoc の記法に従い十分なドキュメンテーションを行うこと.

- PFCs have to work on all widely used platforms (Windows, Linux, *BSD,
Mac OS X), except where it doesn't make sense.

利用者の多いプラットフォームでは必ず動作すること.
ただしクラスがそのプラットフォームで動いても意味のない場合は例外とする.

- PFCs have to have customizible error reporting (ie. they inherit PEAR
so users can do $obj->expectError() and so on).

カスタマイズ可能なエラー生成を行うこと.
つまり ユーザーで $obj->expectError() のような操作によりエラー処理が行えるよう, PEAR 基底クラスを継承すること.

- PFCs do not break BC without providing users enough time to adjust. A
well thought upgrade path should be provided.

BC って何ですか (;;

- PFCs have to work with error-reporting set to E_ALL and throw no
NOTICEs, WARNINGs.

error_reporting が E_ALL の状態で動作すること.
この際 NOTICE や WARNING のエラーを吐いてはならない.

- PFCs have to work with register_globals = off

register_globals が off の状態で動作すること.

- PFCs have to run on each released PHP-version since 4.2. If PHP 5 has
matured, they have to run on PHP 5 as well. If new functionality of later
versions is needed, PFCs should provide a user-land implementation of this
functionality.

PHP 4.2.x 以降のそれぞれのバージョンで動作すること.
PHP5 がリリースされた際には PHP5 でも動作すること.
前方互換のない PHP 関数を使う際にはそれに相当するユーザーランドを提供すること.
( 単に動けばいいのか, その PHP 関数に該当する機能を自分で実装しろと言っているのか.. 後者なら痛いが.. )

- PFCs should keep the dependencies on non-standard extensions as low as
possible. There should always be a fallback, if the extension is not
available.

非標準的な extension への依存は出来る限り抑えること.
また extension が無い場合に備えて代替手段を用意すること.

- PFCs should follow the additional guidelines (to be written) to ensure
that the same approach is taken to solve the same problem. For example,
for pattern
implementations, the same general design and method names are used.

ある一つの目的には決まってある一つの手段が用いられるとの考えに基づき, 追って提供されるガイドラインに従って記述すること.
例えばある特定されたパターンの実装では同じ基本構造, 同じメソッド名を用いること.
( 不安, OO な人のフォロー求む. )

- PFCs have to show some kind of stability (in API-sense) and should be
widely used.

ころころ仕様変更して API の用途など安定性を損なわないこと. また局所的でなく汎用的に使われること.

Further Stuff:
--------------

推奨事項

- PFCs packages are signed with a PFC Key by the PFC core group (see
below).

PFCs パッケージは PFC コアグループが発行する PFC Key のサインをうけること.

- PFCs are automatically tested on upload. If tests fail, the package will
not be published (multiple platform testing?)

PFCs はアップロードに際して自動でテストされること.
テストに失敗した場合は発行されない. (表にでない)
括弧内: マルチプラットフォームテストかなぁ?

Concurrent Packages:
--------------------

パッケージの平行リリース

- Concurrent PFC Packages should be avoided as much as possible. They are
only allowed, if they take a whole different approach to the same problem
and if it's really not fitable in an existing PFC. It is always preferred
to extend existing PFCs before providing a new one.

新しいパッケージは既存のパッケージを拡張して作成することが望ましい.
あるパッケージで二つ以上のバージョンを混在させるパッケージの平行リリースは出来る限り避けること.
平行リリースを許可する例外としては, ある問題に対して全く異なったアプローチを取っている, または既存のパッケージと異なったものである等の場合が考えられる.

Becoming a PFC:
---------------

PFC への認定

- A class can only become a PFC, if at least 2 independent people have
reviewed the code and gave their approval.

ひとつのクラスごとにひとつの PFC として認定される.
少なくとも二人のレビューをクリアし同意を得る必要がある.

- All prerequesites have to be accomplished.

要求される全ての条件を満たしていること.

- If everything is ok, the PFC core group decides, if it conforms to
everything asked for and changes the state of that package in the PEAR
databse. There is no public vote for becoming a PFC, since a class should
become a PFC if it conforms to the points above, and not if the public
thinks it should... [but how do you measure, if a class has enough
documentation/unittesting/etc..]

PFC core group:
---------------

- The PFC core group consists of some (5?) core developers, which decide,
when a class conforms to the standards and can get the PFC badge.

- The PFC core group signs newly uploaded PFC packages

- If more than "some" people want to become a PFC Core member, a public
vote should be held.

- PFC core group does not decide about which classes should go into PEAR.
This is still task of the whole PEAR community and the exact procedure
should be discussed in another RFC. PFC core group should be an
administrative counsil like the php-group and not make "political"
desicions. This wouldn't be in the spirit of php development.

To be discussed:
----------------

- Concurrent Packages: The above point is not very clearly defined. From
my point of view, it would make sensde to not allow concurrent packages in
PFC. But then again, when is a package a concurrent package and when it's
a new one. Who decides that?

- Who has the last saying? If some people want to do something this way
and some the other way, who decides? the lead developer(s)? the community?

- Who can commit to PFCs? at the moment, everyone with a pear-cvs-account
can commit to every package. Shouldn't be this restricted for PFC classes?
Or is this getting to copmlicated for maintaining CVSROOT/avail.

- If there is common approval of this RFC, what should be the next steps?

--
nam...christian stocker    adr...pflanzschulstr. 31, ch-8004 zurich
pho...+41 43 317 9984      www...http://blog.bitflux.ch
mob...+41 76 561 8860      ema...chregu@phant.ch
wor...+41  1 240 5670      gpg...0x5CE1DECB

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[prev in list] [next in list] [prev in thread] [next in thread]

Configure Your Environment | About MARC | We're Hiring! | Want to add a list? Tell us about it. | 10East
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
typodupeerror

人生unstable -- あるハッカー

読み込み中...