Slide 1

Slide 1 text

モジュールメンテナンスを通して感じる 最近の Perl YAPC::Hokkaido DeNA Co.,Ltd Shohei Yoshida

Slide 2

Slide 2 text

自己紹介 ● @syohex ● 京都の組込み企業で 8 年働いてました ● 今年の 7 月から DeNA で働いています AndApp ● API サーバ (Go) ● Windows 向け SDK, 基盤 (C++) ● OSS 活動では主にメンテナンスをしている – Emacs, Perl, Go

Slide 3

Slide 3 text

Perl ● Mouse ● Text::Xslate ● Data::MessagePack, AnyEvent::MessagePack ● Minilla ● plenv ● Perl::Build ● etc

Slide 4

Slide 4 text

その他 ● Emacs – MELPA – markdown-mode, php-mode, coffee-mode, git-gutter, auto-complete, popup.el, go-eldoc, emacs-jedi etc ● Go – peco ● zsh – zsh-completions

Slide 5

Slide 5 text

目次 ● メンテナンスを通じて感じる最近の Perl ● メンテナンスの話 – メンテナ側の話 – コントリビュータ側の話 ● おわりに

Slide 6

Slide 6 text

最近 Perl の印象 ● 一部を除き積極的には開発されていない ● 新しいこともあまり行われない – 新機能開発はあまり行われず – 新しいモジュールも出ない ● 古いモジュールが壊れたまま放置 – パッチ , PR が放置されることが少なくない ● 反応が乏しい

Slide 7

Slide 7 text

モチベーションの低下 ● そもそもあまり触らなくなった ● Perl に革新的なことが起きない – バージョンを重ねるごとによくなっているけど – ( 個人的に ) そこまで熱意を保てるものではない – 技術的チャレンジがない – それでいて壊れることが稀にある

Slide 8

Slide 8 text

昔 Perl を盛り上げていた人たちは ● メインの使用言語が他の言語へ – Java, Scala – Go – Ruby, Python ● みんな年を取った – 自由に使える時間が減った

Slide 9

Slide 9 text

Perl を通じて思うこと ● バリバリ開発している時期ならいいけど , それ をすぎるとメンテナンスは重荷に ● 早めにメンテナンス方針を立てていれば – タイミングとしては開発が一通り完了した時点 – 問題が溜まった後では遅い ● コントリビュータの意識も重要

Slide 10

Slide 10 text

ここから メンテナンスの話

Slide 11

Slide 11 text

メンテナ側の話

Slide 12

Slide 12 text

検討すべきこと ● 継続してメンテナンスする場合 – 負荷を減らす – 共同メンテナンス ● メンテナンスをやめる

Slide 13

Slide 13 text

メンテナンスを継続する

Slide 14

Slide 14 text

負荷を減らす ● issue を閉じて , Pull Request のみにする – 問題調査は骨が折れる – issue だけの人対策 (stackoverflow へ誘導 ) ● 反応がない issue, PR は閉じる – 無駄に溜まった issue, PR の数は精神的によくない ● Issue/PR template は効果はそれほどでもない ● 自動化できるものは自動化を

Slide 15

Slide 15 text

負荷を減らす ● サポート対象を減らす – (Perl だと )5.8 とかいつまでサポートするんだ – 自身に問題ないけど , 依存パッケージの minimum version 更新でテストがこける原因になったりする

Slide 16

Slide 16 text

対応をほどほどに ● No と言おう , 断ろう – 何でも対応しようとすると自分の首を締める

Slide 17

Slide 17 text

共同でメンテナンスする ● 一人は辛い – 辛いときは些細な PR を見るのも面倒 ● 共同メンテナを見つける – commit 権限 – パッケージリリース権限 (Perl だと comaint) ● issue, PR が溜まりまくる前に !!

Slide 18

Slide 18 text

メンテナンスをやめる

Slide 19

Slide 19 text

やりすぎは身を滅ぼす ● 真面目にやりすぎると燃え尽きる ● 他のことにまで影響が出るのはよくない ● 燃え尽きるぐらいならやめた方がいいのでは

Slide 20

Slide 20 text

やめるときは明示的に ● 単に投げ出さない ● 曖昧な状況はよくない – とりあえず github にはあるけれど ● パッチ送っても反応無し ● メールを書いてみても反応無し

Slide 21

Slide 21 text

やめるときは明示的に ● メンテナンスしないことを明記 – ( 早めに )issue, ドキュメントに書く ● ( もう少し ) 余力があれば – 代替手段の提示

Slide 22

Slide 22 text

コントリビュータ側の話

Slide 23

Slide 23 text

Issue, Pull Request ● メンテナは対応に時間がかかる – バグの確認・調査 , レビュー – なるべく時間がかからなく済むよう心がける ● PR は自分のコードを他人に管理してもらうこ とになりうる行為

Slide 24

Slide 24 text

良いレポート ● バグレポート – 再現手順 , 環境の情報 ● 可能な限りミニマルに – 自分が受け取った時 , 再現できて , 直せると思え るものを送ろう

Slide 25

Slide 25 text

良くないレポート ● 動かない , 壊れてるとだけ書かれる どうしろと ● この機能足したら便利なはず 本当に ? ユースケースを提示しよう

Slide 26

Slide 26 text

良くないコメント ● +1, I have same issue – 意味ない , reaction で十分 – 何かコメントするなら新情報を

Slide 27

Slide 27 text

Pull Request の前に ● 過去の PR を調べよう ● 同じことを何度も指摘させないように – かなり萎える原因になっている印象 – あなたにとって一回目でもメンテナは同じことを数 十回言っているかもしれない ● github 等だと過去のコメント数をチェック

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

Feature Request ● 新機能追加 , 拡張などは積極的に提案しよう – やる気のある内しか実現 ( マージ ) できない ● 時期を間違うと一生実現しないかも – バグ対応ばっかりやっているときにそういう提案が あると気持ちの切り替えになることも – ユースケースを示す – コード書く前に一度相談してみる

Slide 30

Slide 30 text

最後に ● ソフトウェアのメンテナンスは大変 – 燃え尽きてしまうことも – 計画的なメンテナンスで負荷の軽減を – コントリビュータの意識でメンテナな負荷は下がる ● Happy maintenance

Slide 31

Slide 31 text

ご清聴ありがとうございました