博士

やあ、ロボ子。今日はオープンソースライブラリのバグにどう対処するか、というお話じゃ。

ロボ子

博士、こんにちは。興味深いテーマですね。アプリケーションが依存するライブラリのバグは、私たちエンジニアにとって悩みの種です。

博士

そうじゃろう？ FooAppがLibBarというライブラリに依存していて、そのLibBarにバグがあるとする。さて、どうする？

ロボ子

記事では、いくつかの一般的な対応とその問題点が挙げられていますね。代替ライブラリへの切り替えはコストがかかり、ライブラリのコードをコピーして修正する方法は、モノレポの維持が必要になる、と。

博士

そうそう。モンキーパッチは特定のバージョンに依存しすぎるし、回避策の実装は責任が曖昧になる。修正をアップストリームに実装するのは、ユーザーにバグのある動作を強いることになるのじゃ。

ロボ子

どれも一長一短ですね。理想的なのは、修正版を一時的に利用する方法を持つこと、と記事にあります。

博士

その通り！ まずは問題を明確に記述して、Issueとしてプロジェクトに報告するのじゃ。

ロボ子

プルリクエストではなく、Issueとして報告するんですね。なぜでしょうか？

博士

プルリクエストは修正提案じゃから、まずは問題の存在を広く知ってもらうことが大切なのじゃ。それから、LibBarのソースコードをフォークして、修正できる場所を確保する。

ロボ子

フォークしたリポジトリで、独自のメインブランチを作成し、CIシステムを構築するんですね。社内アーティファクトリポジトリもオプションで設定できる、と。

博士

そうじゃ。そして、ローカルでLibBarとFooAppのリポジトリを設定して、LibBarの変更を内部フォークに反映させる。テストも忘れずに！

ロボ子

内部で修正版をデプロイして動作を確認したら、LibBarに変更を送信するプルリクエストを作成するんですね。フィードバックを反映して、再度デプロイする、と。

博士

その通り！ アップストリームが変更を反映するまで待って、公式リリースバージョンに戻すのじゃ。追跡タスクを維持して、内部リポジトリを整理することも忘れずに。

ロボ子

なるほど。一連の流れを理解しました。記事では、Pythonパッケージに特化したワークフローについても解説される予定とのことです。

博士

楽しみじゃのう！ ちなみに、ロボ子はバグを見つけるのが得意じゃから、私の研究室のゴキブリホイホイのバグも直してくれるかの？

ロボ子

博士、それはソフトウェアのバグとは違います…。