Apache Subversion とコミュニティへの参加

メーリングリストに参加する

Subversion について議論するための メーリングリスト、IRC チャンネル、フォーラム があります。これらは、技術的な議論、質問への回答、または新規参入者向けの問題解決に興味のあるユーザーや貢献者にとって excellent な情報源です。

Subversion を宣伝する

ブログ、Twitter、Facebook を使用したり、お気に入りのローカル雑誌に記事を投稿したりして、Subversion の宣伝にご協力ください。別のオープンソースコミュニティのメンバーであれば、ディスカッションフォーラムやカンファレンスで Subversion について言及してみてはいかがでしょうか？Subversion が好きなら、遠慮なく声を上げてください！Subversion を使用する開発者が増えれば増えるほど、バグが発見され、機能が追加され、プロジェクトの認知度が高まり、コミュニティの利益が大きくなります。

subversion.apache.org へのリンク

オープンソースプロジェクトの成功は、製品を使用し、プロジェクトに貢献する人の数にかかっています。https://subversion.dokyumento.jp/ にリンクすることで、新しいユーザーや貢献者がプロジェクトを見つけ、コミュニティに参加する可能性が高まります。

バグレポートを提出する

バグレポートの提出には時間はかかりませんが、開発者にとっては非常に役立ちます。これは、最も簡単にできる貢献の 1 つです。Subversion の問題を発見した場合は、報告してください。コミュニティとしては、まず users@subversion.apache.org メーリングリストにバグを報告して、他のコミュニティメンバーが最初のレベルの支援とトリアージを提供できるようにすることをお勧めします。多くの場合、問題の解決策や回答がすでにある場合があります。

既存のバグレポートのトリアージを支援する

Subversion には、かなり多くのバグレポートが寄せられています。私たちは、寄せられたレポートをすべて検証するために最善を尽くしていますが、イシュートラッカー で、重複したバグレポート、誰にも気づかれずに修正されたバグなどをすべて防ぐことはできません。私たちを支援する方法の 1 つは、トリアージが必要な問題 をいくつか見て、バグレポートを読み、Subversion でバグがまだ存在するかどうかを確認することです。その過程で開発者にとって役立つと思われる追加情報が見つかった場合は、問題に注釈を付け、わかったことを共有してください。

再現スクリプトを作成する

よく書かれたバグレポートは、開発者にとって非常に貴重です。しかし、再現レシピスクリプトは、よく書かれたレポートの 100 倍の価値があります。開発者が問題が発生したとき、あなたが何をしているかを理解するのに、あなたと同じことをして、同じ結果を見ること以上に役立つものはありません。残念ながら、多くのバグレポートはメーリングリストやイシュートラッカーから寄せられ、問題の散文的な説明しか提供していません。そのため、もう 1 つの excellent な貢献の機会は、これらの散文的なレポートを信頼性の高い、繰り返し可能な再現スクリプトに変換することです。おそらく、スクリプトテンプレート（unix テンプレート、windows テンプレート）から始めて、レポートに合わせてカスタマイズすることです。これにより、開発者にはいくつかのメリットがあります。開発者が自分でこのスクリプトを作成する手間を省くことができます。多くの場合、スクリプトは Subversion の回帰テストスイートに直接移植できるため、バグが修正されると、修正されたままになります。また、バグレポートに別の目で確認することで、バグが特定のデータセットに固有である、または他の特定の状況下でのみ発生するという事実など、予期せぬ微妙な違いが明らかになることがあります。

ビルドファームにノードを追加する

Subversion には、実行にかなりの時間を要する大規模な回帰テストスイートがあります。開発者は変更をコミットする前にこれらのテストを実行することが推奨されていますが、時には「明白な」変更がそうでないことが判明したり、プラットフォーム固有のバグが発生したりするなど、問題が発生することがあります。このような問題を捕捉するために、コードベースが変更されるたびに継続的にテストを行う ビルドボットファーム を使用しています。そのため、個人的に Subversion を積極的にテストする時間を取れない場合でも、空き時間のあるコンピューターがある場合は、ビルドボットファームのノードとして追加することを検討してください。テストスイートを、追加のオペレーティングシステムとマシンアーキテクチャで継続的に実行することは、常に役立ちます。

ビルドボットノードの構成詳細へのポインタをここに示します。

パッチを送信する

オープンソースのことわざ「パッチ歓迎」は、メーリングリストの荒らしに対するスレッドキラーの反論として最も頻繁に現れるかもしれませんが、この声明の中心には、ソフトウェアコードは自分自身では書かれない、そしてプロジェクトは一般的にできるだけ多くの人にそのコードを書いてもらいたいという 2 つの非常に本物の理想があります。Subversion プロジェクトも例外ではありません。私たちは 数え切れないほどの貢献パッチ を受け入れ、適用してきました。そして、私たちは常に一定の流れを維持したいと考えています。この方法で貢献できる開発者の方は、Subversion コミュニティガイド、特に パッチの提出 と コーディング規約 に関するセクションをご覧いただき、ぜひご参加ください。数週間、あるいは数か月かかるような大規模なプロジェクトを探している方のために、プロジェクトのアイデア のリストを用意しています。

新機能の設計を支援する

大規模な機能は、誰かが時間と意欲を持ったときに書かれるだけではありません。まず設計されます。このプロセスには、dev@ リスト での議論が含まれ、かなり詳細な根拠と実装計画が飛び交います。（私たちはしばしば、提案された設計に取り組むために wiki を使用します。）このような議論に参加することは、ユーザーが計画された新機能が最初からユースケースと要望を満たすように設計されていることを確認するための excellent な方法であり、大規模な機能の場合は、コーディングを行う前に コンセンサス を確立するための鍵となります。

再現スクリプトを回帰テストに変換する

多くの場合、ユーザーまたは開発者はバグについて議論するときに 再現スクリプト を投稿します。バグ修正に関連するタスクの 1 つは、スクリプト（通常はシェルスクリプトまたはバッチスクリプト）を Subversion のテストスイート の Python テストに変換することです。再現スクリプトと同等の XFail（「バグが修正されるまで失敗することが予想される」）テストを実装する パッチを送信する ことは非常に役立つ貢献であり、求められる具体的な修正のデモンストレーションとして役立つと同時に、他の貢献者と開発者がバグの原因と修正の調査により多くの時間を費やすことができます。

コミッターになり、コードを直接コミットする

高品質なパッチを長年送信してきた開発者は、直接コミット権を取得できます。これは明らかに開発者コミュニティにとって有益です。質の高い開発者に関して言えば、「多ければ多いほど良い」のです。しかし、この経験があなた自身と専門的にどれほど貴重なものになるかを過小評価しないでください。