現在のコミッター

コミッターになるには

Sparkへの貢献を始めるには、「貢献方法」をご覧ください。誰でもプロジェクトにパッチ、ドキュメント、サンプルを提出できます。

PMCは、貢献度に基づいて、アクティブな貢献者の中から定期的に新しいコミッターを追加します。新しいコミッターの資格には以下が含まれます。

1. Sparkへの継続的な貢献: コミッターは、Sparkへの主要な貢献の履歴を持つべきです。理想的なコミッターは、プロジェクト全体にわたって幅広く貢献し、少なくとも1つの主要コンポーネントに「所有権」のある役割で貢献してきた人物です。「所有権のある役割」とは、既存の貢献者が、そのコンポーネントのパッチをこの人物に実行してもらうべきだと感じることを意味します。
2. 貢献の質: コミッターは、他のどのコミュニティメンバーよりも、シンプルで、十分にテストされ、設計されたパッチを提出すべきです。さらに、パッチをレビューするのに十分な専門知識を示す必要があり、それには、Sparkのエンジニアリングプラクティス（テスト可能性、ドキュメント、APIの安定性、コードスタイルなど）に適合しているかどうかの確認も含まれます。コミッターは、Sparkのソフトウェア品質と保守性に対して共同で責任を負います。SparkのコアやSQLモジュールなどの重要な部分への貢献は、品質評価においてより高い基準で審査されることに注意してください。これらの分野への貢献者は、変更のレビューをより多く受けることになります。
3. コミュニティへの参加: コミッターは、すべてのコミュニティインタラクションにおいて、建設的で友好的な態度を保つべきです。また、devおよびuserメーリングリストでアクティブに活動し、新しい貢献者やユーザーのメンターとなることも重要です。設計に関する議論では、意見の相違がある場合でも、コミッターはプロフェッショナルで外交的なアプローチを維持すべきです。
4. Apache Way: コミッターは、Apache Way、例えばLazy Consensusに従い、理解する必要があります。Apacheプロジェクトは独立して管理されています。

明らかに特定のベンダーを排他的な方法で優遇するコミュニティは、競合するベンダーからの新しい貢献者を discouraged することになり、これはプロジェクトの長期的な健全性にとって問題となります。

考慮される貢献の種類とレベルは、プロジェクトの分野によって異なる場合があります。たとえば、主にドキュメントに取り組みたい貢献者、または主に特定のOS、ストレージシステムなどのプラットフォームサポートに取り組みたい貢献者を大いに奨励しています。

PMCは新しいPMCメンバーも追加します。PMCメンバーは、Apache Guidanceに記載されているPMCの責任を遂行することが期待されます。これには、リリース投票の支援、Apacheプロジェクトの商標の執行、法的およびライセンス問題への対応、プロジェクトがApacheプロジェクトのメカニズムに従っていることの確認が含まれます。PMCは、これらの活動を理解し、支援できることを示したコミッターを定期的にPMCに追加します。

レビュープロセス

すべての貢献は、Sparkへの貢献に記載されているように、マージされる前にレビューされる必要があります。特に、コードベースの馴染みのない領域に取り組んでいる場合は、そのコードのGit履歴を確認して、以前に誰がパッチをレビューしたかを確認してください。これは、git log --format=full <filename>を使用して、各パッチをコミットした人物を確認するために「Commit」フィールドを調べることで行うことができます。

プルリクエストのコミット/マージ時期

活発な、トピックに沿った議論の最中には、公開されている脆弱性の重要なセキュリティ修正などの問題に対処しない限り、PRはマージされるべきではありません。やむを得ない事情がある場合、PRは活発な、トピックから外れた議論の最中にマージされることがあり、議論はより適切な場所に移されます。マージ前に、会話に関与した人々がトピックに沿っていると信じる理由を説明する時間を設ける必要があります。

Lazy consensusは、人々がSparkをフルタイムの仕事としていない可能性や休暇を取る可能性があることを理解しながら、議論が落ち着くまで時間を置くことを要求します。これにより、人々が拒否権を行使する必要性を感じる頻度を制限できると考えられます。

理由を伴うすべての -1 は議論に値します。コミッターではない人物からの -1 は、複数のコミッターの意見なしには上書きできず、他のコミッターが懸念を表明するのに十分な時間を与える必要があります。連絡の取れないコミッターからの -1 は、ASFのコード拒否権ガイドラインに従って、次のステップを決定するためにPMCのコンセンサス投票を必要とします。

これらのポリシーは、コードが保留中の拒否権をもってマージされたり、コンセンサスが達成される前にマージされたりしてはならないというコア原則を再確認するために役立ちます。

PMCは、拒否権が今後もまれであること、そして発生した場合には、すべての関係者が追加の機能作業を進める前にコンセンサスを構築する時間を取ることを願っています。

コミッターであることは、多様な意見を持つ人々のコミュニティで作業しながら、自分の判断を行使することを意味します。不確かな場合は、2番目（または3番目、4番目）の意見を求めることは何も間違っていません。Sparkプロジェクトへの献身に感謝します。それはSparkの開発者とユーザーに感謝されています。

これらのガイドラインが開発を遅らせないことを願っています。むしろ、不確実性を some 軽減することで、コンセンサスに到達しやすくすることを目標としています。これらのガイドラインやその他のSparkプロジェクトの運用手順を改善するためのアイデアがあれば、dev@メーリングリストに連絡して議論を開始してください。

プルリクエストのマージ方法

Apacheのmasterブランチにプッシュされた変更は削除できません。つまり、force-pushすることはできません。したがって、テストコミットなどを追加しないでください。実際のパッチのみを追加してください。

リモートの設定

以下で説明するmerge_spark_pr.pyスクリプトを使用するには、https://github.com/apache/sparkにapacheという名前のGitリモート、およびgit://github.com/apache/sparkにapache-githubという名前のリモートを追加する必要があります。

apache（PUSH_REMOTE_NAME環境変数のデフォルト値）は、squashされたコミットをプッシュするために使用されるリモートであり、apache-github（PR_REMOTE_NAMEのデフォルト値）は、変更をプルするために使用されるリモートです。これらの2つの別々のリモートを使用することで、PUSH_REMOTE_NAME変数に自分のフォークを指定するだけで、merge_spark_pr.pyの結果を公式Sparkリポジトリにプッシュせずにテストできます。

Sparkのフォークをクローンした後、すでにそこを指すoriginリモートがあります。したがって、正しければ、git remote -vには少なくともこれらの行が含まれているはずです。

apache	git@github.com:apache/spark.git (fetch)
apache	git@github.com:apache/spark.git (push)
apache-github	git@github.com:apache/spark.git (fetch)
apache-github	git@github.com:apache/spark.git (push)
origin	git@github.com:[your username]/spark.git (fetch)
origin	git@github.com:[your username]/spark.git (push)

Apacheリポジトリについては、GitHubへのコマンドライン認証を設定する必要があります。これにはSSHキーや個人アクセストークンの設定が含まれる場合があります。以下を参照してください。

• https://docs.github.com/en/authentication/connecting-to-github-with-ssh
• https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens

必要な書き込みアクセスがすでに付与されているかどうかを確認するには、GitBoxにアクセスしてください。

これらの手順で問題が発生した場合、または最初のマージのヘルプが必要な場合は、dev@spark.apache.orgに問い合わせてください。

マージスクリプト

すべてのマージは、dev/merge_spark_pr.pyを使用して行う必要があります。これにより、プルリクエストの変更が1つのコミットにsquashされます。

スクリプトは非常に自己説明的であり、ステップとオプションをインタラクティブに案内します。

マージ前にコミットを修正したい場合（軽微な修正に使用すべきです）は、スクリプトがApacheにプッシュするかどうかを尋ねてくるところで待機させます。次に、別のウィンドウでコードを修正してコミットをプッシュします。git rebase -i HEAD~2を実行し、新しいコミットを「squash」します。その直後にコミットメッセージを編集して、自分のコミットメッセージを削除します。git logで結果が1つの変更であることを確認できます。次に、別のウィンドウでスクリプトを再開します。

また、該当する場合は、JIRAが解決されたらAssigneeを設定することを忘れないでください。スクリプトはほとんどの場合、これを自動的に行うことができます。

PRがマージされたら、どのブランチにマージされたかを記載したコメントをPRに残してください。

バグ修正のバックポートに関するポリシー

（pwendellより）

バックポートのトレードオフは、古いバージョンを実行しているユーザーに修正を配信できること（素晴らしい！）ですが、メンテナンスリリースで新しい、あるいはさらに悪いバグを導入するリスクがあること（悪い！）です。決定のポイントは、バグ修正があり、バックポートする価値があるかどうかが不明な場合です。

以下の側面が考慮すべき重要な点だと思います。

• バックポートはコミュニティにとって非常に価値のあるサービスであり、あらゆるバグ修正で検討されるべきです。
• メンテナンスリリースで新しいバグを導入することは、あらゆるコストをかけて回避しなければなりません。それは時間の経過とともにリリースプロセスへの信頼を損なうでしょう。
• ディストリビューションや高度なユーザーは、必要であれば、リスクの高いパッチを自分でバックポートできます。

私にとって、これらの結果は、以下の状況でバックポートすべきであるということです。

• バグと修正の両方がよく理解され、分離されている。コードはよくテストされている。
• 対象となるバグはコミュニティにとって優先度が高い。
• バックポートされた修正は、マスターブランチの修正から大きく逸脱しない。

反対の状況では、バックポートを避ける傾向があります。

• バグまたは修正がよく理解されていない。たとえば、複雑なコンポーネント間またはサードパーティライブラリ（Hadoopライブラリなど）との相互作用に関連している。コードは、修正対象のバグ以外ではよくテストされていない。
• バグがコミュニティにとって明確に高優先度ではない。
• バックポートされた修正は、マスターブランチの修正と大きく異なる。