序文

最近、より個人的なもの（ジョブを変更、移動、短い休憩）ので、彼らは何の機会のブログ更新していないが、つい最近私を警告する電子メールを受け取りました。

これは、オープンソースプロジェクトに関わっ事について話をする記事を書く時間である（実際、最近ペン不足期間を入力します）。

PS：このようなギフト中秋節、プラス受信する初めてDubboのアクティブおよびアリコミュニティの重要性を、まだやってPRCのサービスやマイクロ技術選択は友人とみなすことができますDubbo。

オープンソースに参加します

今、オープンソースに関わる特定の事柄について話をします。

大手外資系開発者をほぼ毎日の開発者のすべては、一昔前よりも環境にさらさ利便もたらしたオープンソースプロジェクトでも収益を、お楽しみいただけますあるいは数年前にオープンソース運動は、常にされています。

しかし、数年の国内のインターネット企業が徐々に国際的影響力を拡大するためにも大幅に、開発の私達のレベルを向上させBAT、多くの優れたオープンソースプロジェクトを主導しました。

今でもオープンソース・プロジェクトに参加しても、メーカーを取得するための別の方法offer、実際には、私の友人の多くが参加したい、このことは、第一印象は容易ではない与えかもしれないが、それは最初の段階で立ち往生しています。

具体的な手順

以下は私の個人的な経験の主要なステップの概要です：

問題を特定したり自分自身を紹介しますfeature。
フォークソース。
地域開発、セルフテスト。
販売開始pull request。
コミュニティを待ちますCode Review。
コミュニティ入力調整コードにフォローアップ。
承認は、にマージmaster、ブランチこの貢献の完了を。

今私は、最新の参加結合しますDubbo特定のプロセスについて話をします。

問題を特定または機能自分自身を紹介します

最初のステップは、当然、この寄与は、独自であるかを把握する必要がありますか？通常、問題を解決したり、新しいものを提出しfeature、前者は比較的それらより簡単です。

もちろん、この問題は、独自の過程で、それも解決すべき課題のリストを指定できます見つけることができます。

この問題には、例えば、私が見つけたものの過程で、また関連する提出課題をし、記事のレコードを書いて、問題を解決：何を？ダボは二時間にサービスを開始します！

最高のは、すでに重複を避けるために、問題を提出する前に、キーワード検索の下に関連する問題を通じ発行されたリストの最初にあることは注目に値します。

多分コミュニティはフォローアップを行います同じ時間を提出した後、マークされたinvalidラベルが問題と考えられ、または位置を使用しないでも可能ですされていません。

フォークソース、ローカル開発

これは、あなたがそれに取り組んで開始することができたときに、修復されていると判断され問題となっています。

最初のステップは、自分の倉庫にソースコードをコピーし、自然です。

それからちょうど地元の発展に、独自のソースコードリポジトリのクローンを作成する必要があります。

私が遭遇した問題の下の最初のレビュー。

それは単に開始されたDubbo位置決めした後、非常に遅いサービスをmainスレッドがマシンに取得してIPブロックされています。

だから私は、プログラムを提案している：ローカルIPへのプラスのタイムアウトのアクセス、タイムアウトが例外をスローするか、再度リトライが、少なくともログのユーザ位置の問題を持っている必要があります一度。

問題は、メインスレッドがここにブロックされたままになるということですInetAddress.getLocalHost().getHostAddress()が、それは我々が外に出ているかどうかを判断ブロックされてどのくらい知っている必要があります。

あなたが唯一検出するタイミングスレッド、その後の追加、開くことができますmainスレッドがタスクを完了したかどうかを、次は私の最初のPRの内容です。

ここでの焦点は、それは単純に次のステップである、技術的な詳細を議論することではありません。

スレッドプール1の大きさを宣言するに達しました。
次いで、宣言volatileフラグがタスクを完了するためにメインスレッドがあるかどうかを決定するために使用されます。
これは、新しいスレッドがするのを待つための条件を宣言します。
最後に、これだけフラグを決定するために使用することができ、このスレッドを実行する必要があります。

どのように自己診断テスト

次のステップの完了後、これらの項目を実行するために、他のプロジェクトのための基礎としてのパッケージに依存していることから、セルフテストを開発することであるので、我々は通常、（単一の測定を除く）、テストのプロセス全体に関係する新しいプロジェクトを作成する必要があります。

ここで私は注目に値するいくつかのヒントがあると思います。

最初はバージョン番号であり、それを使用する必要があるので、ローカルテストので、mvn clean installテストのために他のプロジェクトに行くために、ローカルに依存するインストールパッケージを。

私たちは、コードの公式バージョンから引き出さ以来、しかし、Mavenの中央リポジトリ（リリースまたはスナップショットのいずれか）に公開されているので、私たちは、JARパッケージのいくつかのバージョンの存在下で、地元の倉庫を持っている必要があります。

私たちが実行したらmvn clean install、自分の地元高い確率をインストールするには、変更されたコードは間違って行く可能性があるときに（おそらく私の立場にはない）、これは彼らの新しいコードに依存することはできません新しいプロジェクトにつながります。

だから私は、通常の練習は、バージョンが変更され、このバージョンは、中央の倉庫に公式にリリースされていない、あなたは私たちがもはやテストのこのバージョンに依存しないように、あなたは、新しいバージョンへのローカルインストールにコードを追加してくださいすることができますことができます。

しかし、提出時に任意のこのバージョン番号を提出取得しないように注意してください。

プルリクエストを開始

セルフテストの完了を開始することができた後にpull request効果を、そしてない、コードの改行の問題に注意する場所を持つことがありました。

改行は、ソースリポジトリと矛盾したら、gitあなたは、この改正が再び投稿を削除することだと思いますので、しますcode review偉大な迷惑をかけます。

このように、明らかに私は行数を変更あまりありませんが、gitあなたは彼らがあなたが場所を変更するかわからない監査につながる、再び覆されとして認識されています。

最も簡単な方法は、独自に設定することでgit、あなたが参照できるグローバルコンフィギュレーション、ここを。

# 提交时转换为LF，检出时转换为CRLF
git config --global core.autocrlf true

# 提交时转换为LF，检出时不转换
git config --global core.autocrlf input

# 提交检出均不转换
git config --global core.autocrlf false
复制代码