パネディスのメモは苦手なので、気になったところをメモる。
speakers
- Thomas Gleixner, linutronix;
- Stephen Hemminger, Vyatta; (ネットワークとか、APIとか)
- Zefan Li(カーネル開発者 カーネルにバグを見つけて、)
- Grant Likely, Linaro;(デバイスまわりで色々開発している)
- Moderated By Greg Kroah-Hartman, The Linux Foundation
メーリスにポスト→メンテナが見るorサブシステムのオーナーが見る
もう少しドキュメントが必要かも。
ドキュメントの書き方
データモデルを理解する コードを追加するならば、initializationを行う
子供が3人大学に行ってるのでまだ引退できないけど、孫がいるからその時間はほしい。
Zefan 「皆がハッピーじゃない。手順がアグレッシブすぎるってGoogleの人が文句言ってる」
Stephan「問題はエンコーディング、シンタックス」 Grant「パッチ自体はよく出来てても、それがカーネル全体で何年も運用できるに足るものかどうか判断するのは難しい」 Stephan「いいレビュー、いいドラフトが書けることを望むしかない」 Grant「経験のある人に見てもらうしかないね」
Grant「継続的改善が重要」
「メーリスみなよ！」
「誰かがやっていることを学ぶ。パッチを読むことから始める」
Zefan「SQLまわりのパッチを作るのは自分しかいない」
IRCチャンネルはない(時差的にリアルタイムの応答がしんどい)。メールしかない。
changelogを書くのは難しくない。changelogをsubmitしないほうが問題である。 ログについて、きちんと理由を書いてほしい。
新機能追加したら、どうしてそれが必要なのかを書く。 ソースコードだけでは意図が読めない。
パッチを開発する。数年後見る。「なんでこのコード書いたんだろう」というふうにならないようにするために ドキュメントとコミットログが必要になる。コメントにコードを入れることには重要である。
zefan 家にいるときは最新カーネルをラップトップで使う。 stephan ほとんどの開発はQEMUを使っている
若い人へのメッセージ アドバイス
興味のあることから始める
- 命令されてやってもダメなんで
- コンパイルエラー
パッチを送ってみよう
- 問題を記述するだけのパッチでもいい
- 適切に問題を直す、だけではなく指摘するだけでもいい
- パッチがポンコツでも、ポンコツなりにパッチを送ったことには理由があるとレビュアーが気づいてくれるから
- パッチを送ってくれればレビューされる。レビュアーのいうことをきく。レビューのフィードバックに時間をかける。
- エゴが強すぎて全てのコメントを受け入れられないことが往々にしてある
- 急いでやることで却って悪くなっちゃうことがあるから気をつける
- コメントの意味がわからなければ聞き返してみる。コメントは短くて何を言っているかわからんことがあるので
- レビュアーの言うことを聞かない人は見捨てられてしまう
あまりないやり方で使ってみる
- SQL読んでくれ
メンターを見つける
- 教えて貰う人を見つける
- ポジティブなフィードバックがいいと思う「イイね！」
- メーリスからポジティブなフィードバックは得られない
やりたいことを見つける
- カーネルだけじゃなく、プロジェクトに参加して、自分が関心のあることから始める
