モジュールメンテナンスを通じて感じる最近のPerl
モジュールメンテナンスを通して感じる最近の PerlYAPC::HokkaidoDeNA Co.,Ltd Shohei Yoshida
View Slide
自己紹介●@syohex●京都の組込み企業で 8 年働いてました●今年の 7 月から DeNA で働いていますAndApp●API サーバ (Go)●Windows 向け SDK, 基盤 (C++)●OSS 活動では主にメンテナンスをしている– Emacs, Perl, Go
Perl●Mouse●Text::Xslate●Data::MessagePack, AnyEvent::MessagePack●Minilla●plenv●Perl::Build●etc
その他●Emacs– MELPA– markdown-mode, php-mode, coffee-mode, git-gutter,auto-complete, popup.el, go-eldoc, emacs-jedi etc●Go– peco●zsh– zsh-completions
目次●メンテナンスを通じて感じる最近の Perl●メンテナンスの話– メンテナ側の話– コントリビュータ側の話●おわりに
最近 Perl の印象●一部を除き積極的には開発されていない●新しいこともあまり行われない– 新機能開発はあまり行われず– 新しいモジュールも出ない●古いモジュールが壊れたまま放置– パッチ , PR が放置されることが少なくない●反応が乏しい
モチベーションの低下●そもそもあまり触らなくなった●Perl に革新的なことが起きない– バージョンを重ねるごとによくなっているけど– ( 個人的に ) そこまで熱意を保てるものではない– 技術的チャレンジがない– それでいて壊れることが稀にある
昔 Perl を盛り上げていた人たちは●メインの使用言語が他の言語へ– Java, Scala– Go– Ruby, Python●みんな年を取った– 自由に使える時間が減った
Perl を通じて思うこと●バリバリ開発している時期ならいいけど , それをすぎるとメンテナンスは重荷に●早めにメンテナンス方針を立てていれば– タイミングとしては開発が一通り完了した時点– 問題が溜まった後では遅い●コントリビュータの意識も重要
ここからメンテナンスの話
メンテナ側の話
検討すべきこと●継続してメンテナンスする場合– 負荷を減らす– 共同メンテナンス●メンテナンスをやめる
メンテナンスを継続する
負荷を減らす●issue を閉じて , Pull Request のみにする– 問題調査は骨が折れる– issue だけの人対策 (stackoverflow へ誘導 )●反応がない issue, PR は閉じる– 無駄に溜まった issue, PR の数は精神的によくない●Issue/PR template は効果はそれほどでもない●自動化できるものは自動化を
負荷を減らす● サポート対象を減らす– (Perl だと )5.8 とかいつまでサポートするんだ– 自身に問題ないけど , 依存パッケージの minimumversion 更新でテストがこける原因になったりする
対応をほどほどに●No と言おう , 断ろう– 何でも対応しようとすると自分の首を締める
共同でメンテナンスする●一人は辛い– 辛いときは些細な PR を見るのも面倒●共同メンテナを見つける– commit 権限– パッケージリリース権限 (Perl だと comaint)●issue, PR が溜まりまくる前に !!
メンテナンスをやめる
やりすぎは身を滅ぼす●真面目にやりすぎると燃え尽きる●他のことにまで影響が出るのはよくない●燃え尽きるぐらいならやめた方がいいのでは
やめるときは明示的に●単に投げ出さない●曖昧な状況はよくない– とりあえず github にはあるけれど●パッチ送っても反応無し●メールを書いてみても反応無し
やめるときは明示的に●メンテナンスしないことを明記– ( 早めに )issue, ドキュメントに書く●( もう少し ) 余力があれば– 代替手段の提示
コントリビュータ側の話
Issue, Pull Request● メンテナは対応に時間がかかる– バグの確認・調査 , レビュー– なるべく時間がかからなく済むよう心がける●PR は自分のコードを他人に管理してもらうことになりうる行為
良いレポート●バグレポート– 再現手順 , 環境の情報●可能な限りミニマルに– 自分が受け取った時 , 再現できて , 直せると思えるものを送ろう
良くないレポート● 動かない , 壊れてるとだけ書かれるどうしろと● この機能足したら便利なはず本当に ?ユースケースを提示しよう
良くないコメント●+1, I have same issue– 意味ない , reaction で十分– 何かコメントするなら新情報を
Pull Request の前に●過去の PR を調べよう●同じことを何度も指摘させないように– かなり萎える原因になっている印象– あなたにとって一回目でもメンテナは同じことを数十回言っているかもしれない●github 等だと過去のコメント数をチェック
Feature Request●新機能追加 , 拡張などは積極的に提案しよう– やる気のある内しか実現 ( マージ ) できない●時期を間違うと一生実現しないかも– バグ対応ばっかりやっているときにそういう提案があると気持ちの切り替えになることも– ユースケースを示す– コード書く前に一度相談してみる
最後に●ソフトウェアのメンテナンスは大変– 燃え尽きてしまうことも– 計画的なメンテナンスで負荷の軽減を– コントリビュータの意識でメンテナな負荷は下がる●Happy maintenance
ご清聴ありがとうございました
syohex
parttimenerd
zakky21
niftycorp
commojun
gregonnet
rdmueller
os1ma
piyoppi
yusukebe
huffon
cherdarchuk
hatefulcrawdad
bryan
smashingmag
danielanewman
cromwellryan
dotmariusz
chrislema
thoeni
bkeepers
frogandcode
colly