私の最初のカーネルへの貢献が奪われた

• 著者は、PowerPC32アーキテクチャ上で動作するgdbserverとマルチスレッドアプリケーションを含むプロジェクトのデバッグ問題に対処していた。
• 問題は、gdbserverへの接続が切断され、デバッグセッションをこれ以上制御できなくなったことだった。
• 調査と検証の結果、著者はこの問題を引き起こした正確なコミットを指し示すメールスレッドを発見した。
• 著者は、PowerPCアーキテクチャとtask_struct周辺の変更に関するコミット説明を読むのに3〜4日を費やし、この問題が後続のカーネルバージョンで解決されているかどうかを把握しようとした。
• 著者は、thread_structスレッドの移動、paholeによるtask_structのレイアウト検査、ftraceを使ったデバッグ対象プロセスのスレッドがいつスケジューリングされるかの特定など、さまざまなツールと手法を用いた。
• 著者は、この問題がメモリ破損の問題である可能性を突き止めた。停止したスレッドは、他のスレッドと異なり一度しかスケジューリングされなかった。
• 著者はLinuxでハードウェアブレークポイントを使い、__stateフィールドにハードウェアブレークポイントを配置して、誰がそこに書き込んでいるのかを特定するためのLinuxカーネルモジュールを実装した。
• 著者は、問題の原因がptrace_put_fprのバッファオーバーフロー（POKEUSER APIで使用される）にあり、その結果task_structの重要なフィールド、たとえば__stateが上書きされていることを発見した。
• 著者は、この問題がセキュリティ上の問題を引き起こす可能性があるため、この不具合を修正するパッチをLinuxカーネルのセキュリティチーム（[e-mail]）に送った。
• PowerPCメンテナのMichael Ellermanは、著者のパッチを受け入れる代わりに、自身の版の修正を実装した。
• 著者は、自分の作業が正当に認められず、軽視されたように感じて怒りを覚えた。与えられたのはReported-byタグだけだった。
• 著者にとって最初のカーネルへの貢献は、自分の作業に対する適切な評価の重要性を重く見ない人々とのやり取りを通じて、強い苛立ちと落胆に満ちた経験だった。

[GN⁺]

Hacker Newsの意見

• 投稿者のパッチは完全には受け入れられなかったが、メンテナーがそのアイデアを使ってセキュリティ問題を解決した状況に関する記事
• 完全なパッチが受け入れられなかったとしても、メンテナーは投稿者にクレジットを与えるべきだったという一部のコメント
• メンテナーのパッチのほうがより優れていて効率的だという主張とあわせて、投稿者が問題を見つけて解決策を提案したことへの認知は必要だという別の主張
• Linuxカーネルは報酬ではなく、メンテナーには最善の解決策を選ぶ権利があるというコメントとともに、投稿者にクレジットを与えることの重要性を強調する一部のコメント
• パッチのアイデアを提案した人にクレジットを与える方法として、カーネル文書の"Suggested-by"タグへの言及
• これはカーネルへの貢献ではよくあることであり、主な目標はクレジットを得ることではなくバグを修正することだという一部のコメント
• オープンソースプロジェクトで自分の貢献が無視されたり完全には受け入れられなかった経験を共有するコメント。これは追加の貢献を妨げる可能性がある
• 投稿者のパッチとメンテナーのパッチを比較し、違いを指摘したうえで、元の作者にクレジットを与えるべきだったと示唆するコメント
• 後輩チームメンバーの貢献を、学習と改善を促す形でどう扱うかという重要性にも議論が触れている
• 否定的な反応への困惑を示すコメント。認知は重要であり、共同著者を追加するのは小さいが意味のあるジェスチャーだと主張
• 外交の重要性と、オープンソースプロジェクトで長期的な関係を維持することについてのコメントで議論が締めくくられる