現在のコミッター

コミッターになるには

Sparkへの貢献を始めようとする場合、貢献方法を学ぶことから始めましょう。誰でもプロジェクトにパッチ、ドキュメント、例を提出できます。

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

1. Sparkへの継続的な貢献：コミッターは、Sparkへの主要な貢献の履歴を持っている必要があります。理想的なコミッターは、プロジェクト全体に広く貢献し、「オーナーシップ」の役割を担った少なくとも1つの主要なコンポーネントに貢献しているでしょう。オーナーシップの役割とは、既存の貢献者が、このコンポーネントのパッチはこの人物によって実行されるべきだと感じていることを意味します。
2. 貢献の質：コミッターは、他のコミュニティメンバー以上に、シンプルで、十分にテストされ、よく設計されたパッチを提出する必要があります。さらに、パッチをレビューするのに十分な専門知識を示す必要があり、Sparkのエンジニアリングプラクティス（テスト可能性、ドキュメント、APIの安定性、コードスタイルなど）に適合していることを確認する必要があります。コミッターシップは、Sparkのソフトウェアの品質と保守性を共同で責任を負います。Sparkの中核やSQLモジュールなどの重要な部分への貢献は、品質を評価する際に、より高い基準が適用されることに注意してください。これらの分野への貢献者は、変更のレビューが増えることになります。
3. コミュニティへの参加：コミッターは、すべてのコミュニティとのやり取りにおいて、建設的で友好的な態度を持つ必要があります。また、開発者およびユーザーリストでアクティブに活動し、新しい貢献者やユーザーを指導する必要があります。設計に関する議論では、意見の相違があった場合でも、コミッターは専門的で外交的なアプローチを維持する必要があります。

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

PMCは、新しいPMCメンバーも追加します。PMCメンバーは、リリースの投票への参加、Apacheプロジェクトの商標の施行、法的およびライセンスの問題への責任の分担、Apacheプロジェクトのメカニズムへの準拠など、Apacheガイダンスに記載されているように、PMCの責任を果たすことが期待されています。PMCは、これらの活動について理解し、支援できることを示したコミッターを定期的にPMCに追加します。

レビュープロセス

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

プルリクエストをコミット/マージするタイミング

公開された脆弱性の重要なセキュリティ修正などの問題に対処する場合を除き、アクティブで話題に沿った議論中にPRはマージされません。例外的な状況では、アクティブで話題に沿っていない議論中にPRがマージされ、議論がより適切な場所に移動される場合があります。会話に関わっている人々が、話題に沿っていると信じているかどうかを説明するために、マージする前に時間を与える必要があります。

遅延コンセンサスとは、人々がSparkをフルタイムの仕事として行っていない可能性があり、休暇を取る可能性があることを理解しながら、議論が落ち着く時間を与えることを必要とします。これを行うことで、拒否権を行使する必要を感じる頻度を制限できると考えられています。

正当な理由のあるすべての-1は議論に値します。非コミッターからの-1は、複数のコミッターからの入力によってのみ上書きでき、コミッターが懸念事項を提起するための適切な時間を提供する必要があります。連絡が取れないコミッターからの-1は、ASFコード拒否権に関するガイドラインに従って、次の手順を決定するために、ASF投票規則の下でPMCのコンセンサス投票が必要です。

これらのポリシーは、拒否権が保留されている場合、またはコンセンサス（遅延しているかどうかにかかわらず）に達する前に、コードをマージしてはならないという基本原則を繰り返すものです。

PMCは、拒否権が引き続きまれであることを望んでおり、発生した場合、すべての当事者が追加の機能作業の前にコンセンサスを構築するために時間をかけることを望んでいます。

コミッターになるということは、さまざまな見解を持つ人々のコミュニティで作業しながら、自分の判断力を発揮することを意味します。不確かな場合は、第2（または第3、第4）の意見を得ることに何も問題はありません。Sparkプロジェクトへのご尽力に感謝いたします。それはSparkの開発者とユーザーによって高く評価されています。

これらのガイドラインが開発を遅くすることはありません。むしろ、不確実性の一部を除去することにより、コンセンサスに到達しやすくすることを目指しています。これらのガイドラインまたはその他のSparkプロジェクト運用手順を改善する方法に関するアイデアがある場合は、dev@リストに連絡して議論を開始してください。

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

Apacheのマスターブランチにプッシュされた変更は削除できません。つまり、強制プッシュすることはできません。そのため、テストコミットなどは追加しないでください。実際のパッチのみを追加してください。

リモートの設定

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

apache（PUSH_REMOTE_NAME環境変数のデフォルト値）は、圧縮されたコミットをプッシュするために使用されるリモートであり、apache-github（PR_REMOTE_NAMEのデフォルト値）は、変更をプルするために使用されるリモートです。これらの2つのアクションに対して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にお問い合わせください。

マージスクリプト

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

スクリプトは非常に分かりやすく、手順とオプションを対話的に説明します。

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

また、該当する場合は、JIRAの担当者を解決時に設定してください。スクリプトはほとんどの場合、これを自動的に実行できます。

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

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

pwendellより

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

考慮すべき重要な要素は以下のとおりです。

• バックポートはコミュニティにとって非常に貴重なサービスであり、バグ修正にはすべて検討する必要があります。
• メンテナンスリリースに新しいバグを導入することは、絶対に避けなければなりません。時間の経過とともに、リリースプロセスに対する信頼が損なわれます。
• 必要に応じて、ディストリビューションまたは上級ユーザーは、リスクのあるパッチを独自にバックポートできます。

これらの結果から、私は以下の状況でバックポートを行うべきだと考えています。

• バグと修正の両方が十分に理解され、分離されています。修正されたコードは十分にテストされています。
• 対処されているバグは、コミュニティにとって高い優先度です。
• バックポートされた修正は、マスターブランチの修正と大きく異なりません。

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

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