リポジトリへのアクセス権

collective のメンバーは全員、完全なコミット権を持ちます。 ちょっとしたバグフィックスなら、主開発者の許可を得ずにコミットすることができます。 しかし、礼儀として、 何かアクションを起こす際にはそのパッケージの主開発者と連絡を取るよう心がけましょう。 コミットした内容について議論が起こった場合は、 とりあえずいったんそれを revert してレビューを行いましょう。

この規則は、オープンでフレンドリーな共同作業を進めるために用意されたものです。 PHP プロジェクトの開発者たちもこの規則にのっとって作業をしており、 スレッドセーフ関連のエラー対応やスペルミス対応などのちょっとした修正については 確認することなくいきなりコミットしてしまっています。 この規則に例外をもうける場合は、ウェブサイト上に記載があるように PEAR グループの許可が必要です。

パッケージ設計について

設計に関する決定は、各 Collective で自由に議論することができます。 そして、自分たちで決めたことを自分たちのやり方で守っていきます。 基本的なインターフェイスを決めている Collective もあれば共通の保存フォーマットを決めている Collective もあるでしょう。パッケージの開発者は、 これらの決まりを守ってパッケージをよりよいものにしていかなければなりません。 勝手に無茶なコーディングをしてはいけません! (No cowboy coding!) パッケージの開発者には余計な口出しをされずに開発を進める自由はありますが、 pear.php.net でコードを公開するには 建設的な批判は受け入れてもらわなければなりません。

リリース

All collective members can pull a release within 24 hours if there is a major regression or security bug. If at all possible, the primary lead maintainers should perform this action, but Collectives function as a unit, and have the role of policing huge problems.

競合するパッケージ

Competing packages are allowed at the alpha level in PEAR2.

All alpha/devel stability packages have no claim to a package name. If a better package comes along that does the same thing, wants your package's name and achieves beta status, you have to either join forces or change the name of your package. The limit is that newer packages have to be unarguably better in implementation. It is up to the Collective to define "unarguably better"

古くなったパッケージ

Any package that is alpha (in svn.pear.php.net/PEAR2/sandbox) and inactive for more than a year will be deleted

ベータ版とは

To become beta, a package must undergo extensive review.

• documentation must be complete.

• full test suite must demonstrate 50% code coverage

• API must be approved by 2/3 of the collective developers (this will probably be a blanket stamp for most packages)

• all developers in a collective (including alpha package maintainers) can vote on whether a package is ready for beta status

• a final name for the package must be chosen by the lead developers of the package that does not conflict with the existing beta+ packages. Names are chosen on a first-come-first-serve basis.

Package acceptance into PEAR2

Packages can be proposed either as 1) A completed, or relatively complete package to Pepr 2) A concept, or proof-of-concept to svn.pear.php.net/PEAR2/sandbox For proof-of-concept packages they should

• Post a public notice to the pear-dev mailing list stating the intention to begin development.

• Request a new package be created on the pear.php.net website

• Undergo a review by the collective (as defined in the previous section) when ready to move from alpha to beta stability

• Once the review is complete, the package developers may request an official vote by the collective on whether the package is ready. The vote is conducted through PEPr. Unsuccessful packages may request a second review after fixing issues noted by the collective.

• Successful packages may then move their development directly from svn.pear.php.net/PEAR2/alpha into svn.pear.php.net/PEAR2 using svn move.

Packages listed in the channel

Only packages with a status of beta or stable are added to the public channel

Version Control System

In order to submit code to PEAR2 you will need to use the provided svn repository.