Sparkへの貢献コトハジメ

2015年はSparkだ、と勝手に思っています。で、社内で自分の関わるサービスの裏側で利用する箇所をどんどん増やしていくのももちろんですが、これまでまともにOSSに貢献していなかったので、これを気にOSSへの貢献にもチャレンジしてみようかと思ったりしたので、色々調べてみた備忘録です。

基本情報

何かできないかな、ということで Contributing to Spark を読んで適当に要約してみます。

Reporting Issues

バグとか質問する時はJIRAでissueをopenするかMLにて。

Contributing Code

githubのPull Requestで受け付けている。JIRAでissueをopenにした上でgithubのsparkリポジトリでのPRでレビューを行う。

という感じでしょうか。

Criteria for Inclusion or Rejection of Patches

Sparkの正しさ(バグフィックスとか？)に関するパッチであり、小さく、多くのユーザーにとって有益であるものは即座にレビューされ、マージされる。そうでないもの(以下のもの)は時間がかかったり、場合によっては拒絶される。

  • 変更が多いコードや正しさの確認が難しいもの
  • Sparkそのものよりもサードパーティに手を入れているようなケース
  • 複雑過ぎるもの
  • 明示的にせよ、暗黙的にせよユーザーに依存するような振る舞いをするもの(退化と表現されている)
  • 新しいAPIを追加しようとするもの
  • 依存関係を追加するもの

小さなパッチはほぼリジェクトされない。

Contributing New Algorithms to MLLib

MLLibの重要なゴールはアルゴリズムをたくさん揃えていることである一方で、プロジェクトのメンテナンス性や一貫性、品質が第一の要求のため、実装されるアルゴリズムは

  • よく知られている
  • 利用され、受け入れられている
  • 高いスケーラビリティがある
  • よくドキュメント化されている
  • 他のアルゴリズムとAPIの一貫性を保たせる
  • 開発者のサポートが得られる

であるべき。

Automated Testing

全てのパッチには自動テストが行われる。

Starter Tasks

Sparkコントリビュータになりたいならまずはここからなチケット集

Documentation

2つの方法がある

  • 外部でチュートリアルを書いてそれを加えたい場合は、開発者MLに投げる
  • ビルトインのドキュメントに変更を加える場合は、MarkDown記法で編集を行い、githubのリポジトリにパッチを送る

Development Discussions

開発社MLにての議論

IDE Setup

IntelliJ

SBTやMavenコマンドをよく使うので一番よく使わえれているIDEはIntelliJなので早速コミュニティエディションをゲットする。

Eclipse

Eclipseも使われているよ〜という話だけどもういいや。。。

という感じです。さらに調べたり勉強したりしないといけないものが色々増えました。