Commit access/ja


 * How to become a MediaWiki hackerを下敷きにしています. 
 * The Subversionのページが役に立つかもしれません. 

このページはMediaWikiへのコミットアクセスを始める時に必要な作業の概要を説明しています. このページに書かれていない便利な情報がありましたら、追加して下さい.

セットアップする
svn checkout svn+ssh://myUserName@svn.wikimedia.org/svnroot/mediawiki/trunk/phase3 wiki
 * 1) 最初に、主要な開発者からコミットパーミッションが必要です.
 * 2) SSH公開鍵を利用できるようにします. Linuxシステム上ではｍ~/.ssh/id_rsa.pubファイルに存在します. 例えば、このファイルを個人的なウェブホストにアップロードする場合、URLをアカウントをセットアップする個人に送ります(例えば、http://yoursite.domain.org/id_rsa.pub ). また何のユーザ名が好ましいか示します. この記事ではあなたが"myUserName"を選択したと想定します.
 * 3) アカウントを持ったときに、何かをコミットする前にいくつかの段階に従う必要があります. 最初にSubversionを読んでSubversionのソースコントロールシステムの概要を理解します.
 * 4) それからSubversion/auto-propsを読み、auto-propsをセットアップするためにそこで書かれていることを正しく行います.
 * 5) それから http:// の代わりに svn+ssh:// を使用してチェックアウトする、もしくはそれが単純に動かないです. 一般的に言えば、開発のために使用するよりもコミットのために異なるチェックアウトのコピーを持っておくことは良いアイディアです. パッチを混同する機会を減らすからです. そのためには、次のコマンドを使用します:
 * 1) a USERINFO fileを作成します. 他の開発者があなたに連絡できるように名前と出来ればEメールアドレスも追記しておきます. このファイルはhttp://svn.wikimedia.org/users.php でリストを生成するために使用されます.

パッチを適用するためのガイドライン
cd maintenance php parserTests.php --quiet --quick --color=no ...そして失敗の前後を比較して、回帰現象が起きていないことを確認して下さい.
 * trunkはライブコードを想定していることを覚えておいて下さい -- 最新の状態を維持しいつでも動作できるように準備しておくことが我々のクォリティコントロールの最大のメソッドです. アクシデントで壊れた場合の例外を除いて、コードはいつでも動作しなければなりません.
 * bugzillaで修正したバグもしくは些細な変更であっても、常にRELEASE-NOTESをアップデートして下さい. これはエンドユーザに見える変更についても当てはまります. これは重要なアーキテクチャの変更もしくは書き換えにも当てはまります(ユーザに見えない場合でも)、それらの変更はサードパーティのエクステンションに影響を与えるからです. 利便のために、変更はRELEASE-NOTESの一番後ろに年代順に追加されます.
 * 可能な限りセキュリティの意味合いを考慮して下さい(例えば、エクステンションの作者のためのセキュリティノートを参照して下さい)
 * 事前の許可無しに安定版のtrunkに新しい機能をバックポートしてはなりません. (バックポートとは新しいバージョンで実装された機能を古いバージョンでも利用できるようにすること)実際、安定版のtrunkは単独にしておくのがベストです. 修正のすべてのバックポートはリリースマネージャに任せておけば、面倒なことにしなくて済みます. バックポートされるべきものはセキュリティ修正がされたものや、ソフトウェアが動作するために重要な部分です. 新しい機能は古いバージョンのメンテナンスリリースには追加されません.
 * リリースタグを触らないで下さい. 絶対に.
 * ものを壊そうしないで下さいさもないと他の人が不機嫌になるかもしれません. 例えば、パーサを変更している場合、導入された新しい破損を変更するかどうか決定するのを手助けするために前後でparserTestsを動作させることが出来ます:
 * SVN HEADに適用する前にすべてのパッチをテストして下さい.
 * 異なるフォルダで開発して、開発からパッチを適用する前にコミットコピーでsvn revert -R .を動作させて下さい. これによってパッチが混ざりにくくなります.
 * ツリーが安定版リリースに枝分かれする前に(これは現在3ヶ月ごとに行われます)大きな変更をしないで下さい.
 * 安定版リリースの後でRELEASE-NOTEをアップデートするもっとも最初の人物であった場合(すなわち、新しいサイクルの始め)、手続きはチェンジログエントリー(例えば、"changes since 1.7")をRELEASE-NOTESファイルからHISTORYファイルに移動させることです. 一旦そこに移動させるとRELEASE-NOTESファイルから削除され、新しいセクションが始まります(例えば"changes since 1.8").
 * .CSSもしくは.JSファイルへのアップデート上で$wgStyleVersionの数字をbumpすることを覚えておいて下さい.
 * 変数を再利用使用としないで下さい. またメッセージをgrepしやすくしてして下さい.
 * 後で意味が不明瞭になるかもしれないので論理型のパラメータを使用しないで下さい - 代わりに説明的な名前でクラス定数を使用して下さい.
 * private、public、protectedなど適切に新しい関数もしくは変数をマークすることを努力すべきです.
 * 新しいフックを追加する場合、フックの名前、フックが何をするのかの説明、フックによって使用されるパラメータについてdocs/hooks.txtを更新する必要があります. それもRELEASE-NOTESの"new features"セクションの底に含めるべきです.
 * $_GETもしくは$_POSTよりもWebRequestクラスを使用して下さい.
 * 新しいプリファレンスを導入することは避けて下さい. 可能であるなら良識のあるデフォルトを提供して下さい.新しいプリファレンスが追加されることは非常にまれです.

SVNにコミットをするために

 * 最初に上記で並べられたものに従います
 * IRC (irc.freenode.net)に移動して、#mediawikiに参加し、現在進行中で惨事が起きていないことを確認するために数分待ちます. (そして、惨事が起きているときは、変更をコミットするのにベストタイムではないかもしれません)
 * それから変更をコミットすることが出来ます. 例です:

cd wiki svn commit --message="Your log message here" includes/File-You-Modified.php includes/Another-File-You-Modified.php RELEASE-NOTES

... もしくは望むのであれば、ログメッセージをファイル(../msg.txtファイルなど)に設置します:

svn commit --file ../msg.txt includes/File-You-Modified.php includes/Another-File-You-Modified.php RELEASE-NOTES


 * それから次のような出力が返されます:

Sending       RELEASE-NOTES Sending       includes/User.php Transmitting file data .. Committed revision 16794.


 * それから、"Fixed in r16794." のような行を使用してbugzillaで影響のあるバグ(適用可能な場合)を閉じます. 保存した後、小文字の'r'とリビジョン番号間でスペース無しの、"r####"フォーマットを使用している場合、リビジョン番号はSVNウェブインターフェイスに自動リンクをします.
 * それから少なくとも数分ほど#mediawikiをうろついて、あなたが何か壊したかどか他の人が見つけられるようにします.

便利なリソースもしくはコマンド
svn diff --revision 17109:17114 svn log --revision 17109:17114 --verbose svn merge -r REVISION_NUM_YOU_WANT_TO_UNDO:REVISION_NUM_TO_REVERT_TO. svn status svn diff svn commit --message="Self-revert accidental breakage" includes/file-you-changed.php includes/another-file-you-changed.php
 * 特定のリビジョン番号で変更したことを見るためには、http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=16789 に移動してURLにあるリビジョン番号を適切なものに置き換えます.
 * "svn status"コマンドはローカルバージョンとセントラルバージョン間で異なるファイルを表示します.
 * "svn diff includes/file_you_changed.php"コマンドは最新のチェックアウトしたバージョンに関連して、特定のファイルで何が変更されたのか表示します.
 * コマンドラインから2つのリビジョン間の変更を見たい場合、次のコマンドを使用します:
 * おそらくwikitech メーリングリストを購読すべきでしょう.
 * 最近の変更を見たい場合、CVSメーリングリストを使用することが出来ます.
 * 時にコミット間に小さな遅延があり、CVSのEメールで通知されます. しかしながらSVNではラグは存在しません. 最近の更新もしくはそれほど最新ではない更新を見るためには、"svn log"コマンドを使用することが出来ます. 例えば、これは指定されたリビジョン番号間のすべての変更と、ファイル変更の詳細について表示します:
 * #mediawiki IRCチャネルでいつも質問することが出来ます. CIA-7ボットが動作しているのであれば、SVNコミットの通知を#mediawikiチャネルにプリントアウトします.
 * 変更をコミットして、完全に壊れていることが判明した場合、次のように差し戻すことが出来ます:
 * bugzillaで特定のバグを閲覧するためには、http://bugzilla.wikimedia.org/show_bug.cgi?id=1234 に移動してURLのバグ番号を適切なものに置き換えます.
 * bugzillaでバグを閉じるとき、"Fixed in r."のようなコメントをそれに含みます. それはリビジョンをオートリンクして、バグに関連した変更を追跡するための手助けになります.

稼働させる
SubversionにあるコードはすぐにはWikipediaのようなWikimediaのwiki群で動作しません. サイトの破損を避けるためとコードレビューを可能にするためです.

システムアドミニストレータ(この場合ではBrion VibberもしくはTim Starlingなど)がコード変更をレビューしたときに、彼らはプロダクションクラスタ上で標準的なsvn upを実行します. この時点において、変更はhttp://test.wikipedia.org に反映され、Wikimedia特有のコンフィギュレーションの元で壊れていないか最後の時間の確認が行われます.

OKがすべて表示される場合、変更がアプリケーションサーバに同期化されます. これをする"scap"スクリプトの後で、これは"scapping"としても知られます.

特定の行のコードを修正した最後の人を見つける
次のようにコマンドラインを実行します(例としてincludes/Parser.phpファイルを使用します):

svn blame includes/Parser.php | less

... そして"/"と検索用語(例えば関数名)によって検索します. 生成されたsvnのブレーム出力のために20秒かかることもあります.

どのリビジョンで、行が修正され、誰によって、といったことを表示します:

4452     timwi     $argc = count($args); 9860 kateturner 4452     timwi     for ( $i = 0; $i < $argc-1; $i++ ) { 4904    hashar          if ( substr_count ( $args[$i],  ) != substr_count ( $args[$i],  ) ) { 4904    hashar                $args[$i] .= '|'.$args[$i+1];

... 何故変更がされたのかの説明を取得する何のコミットログメッセージを見るためにSVNウェブインターフェイスを使用して特定のリビジョン番号を探すことが出来ます. 必要ならユーザに尋ねます; コンタクト情報を持ったSVNサーバでSVNコミッターのリストがあります.

非標準的なポートをセットアップする
Tip: SSHのために非標準的なポートが必要なのみ、さもなければ無視します. ~/.subversion/configにこれを追加することでSSHが正しいポート番号を使用することを強制することが出来ます :

[tunnels] ssh = $SVN_SSH ssh -p 22

ブランチングとマージング
ブランチで進行中の実験的な作業をしたい場合、変更をマージする準備が出来るまで開発トランクは安定版を保ちます. ブランチは四半期のリリースのためにも使用することが出来るので追加のバグ修正リリースを簡単に出来ます.

詳細についてはSubversion/branching guide/jaをご覧下さい