アップグレード時にオープンソースソフトウェアにパッチを適用することはできませんか？

私は最近、自分のアプリケーションに統合したオープンソースソフトウェアパッケージで、かなり厄介な（確認済みの）バグに遭遇しました。パブリックイシュートラッカーによると、このバグはソフトウェアの最新リリースで解決されています。

特定のモジュールの高価なリファクタリングを避けるためにバグ修正が必要になる場合がありますが、技術的および/または政治的な理由により、最新リリースにアップグレードすることはできません。

行われたコードの変更を調べると、修正は非常に簡単に思えるので、実行可能なオプションは自分でコードにパッチを当て、現在承認されているバージョンのソフトウェアを再コンパイルすることだと感じますが、中傷者はこれがほとんど常に悪い考えだと主張したいそれは危険であり、面倒な複雑さをもたらします。

彼らの目には、このコードの変更は私たちが使用するためだけに行われたため、コードベースの一部である必要があります。つまり、オープンソースソフトウェアをサードパーティの依存関係として導入するのではなく、新しいプロジェクトとして導入して組み込む必要がありますビルドプロセスへの自動ビルド。

私にとっては、ソース管理リポジトリからコードをソース管理リポジトリにプルするため、これは間違っていると思います。その前に行われたコード変更の背後にある歴史を失います。また、実行する必要のあるこのような小さなコードの変更には、非常に複雑すぎるもののように思えます。

この場合、上記を行うのは悪い考えでしょうか？もしそうなら、オープンソースを変更する必要があるとき、理想的な状況は何ですか？

発生している問題がない新しいバージョンを使用できない場合、唯一のオプションは

• 問題に対処し、回避策を見つける
• ライブラリをフォークし、プライベートバージョンで修正します（これは実際に行うことです）
• タオルを投げて、問題が乗り越えられないことをマネージャーに伝えてください（他に2つの選択肢があるため、これは嘘です）。

私はあなたの立場にいましたが、オプション2（カスタムフォークを作成する）が最も手頃なソリューションです。それはオープンソースライブラリ、特に急速に進化し、リリース間の後方互換性を破る悪い習慣を持っているライブラリを扱うときの人生です（私の経験では、これはこのようなことをしなければならない最も一般的な理由です）。
いくつかのOSSライブラリについては、私とチームを率いて、それらのすべてのラッパーを義務付け、それらのラッパーを介してサードパーティライブラリの機能に排他的にアクセスしました。そうすれば、サードパーティのライブラリを、コードを壊すほど異なるバージョンに置き換える必要がある場合、変更は少なくともそのラッパーに限定されます。最も良い方法ではありません（コードを追加し、複雑さとコストパフォーマンスを追加できます）が、正気を保つ唯一の方法である場合もあります。

あなたがやろうとしていることは、サードパーティのソフトウェアをバンドルしてリリースを追跡しようとするより一般的なケースでは悪い考えです。通常、メンテナーが実装したくない、または必要な方法で実装したくないサードパーティのコンポーネントの機能が必要なため、人々はそうします。

ただし、バンドルされたコードはアップグレードしないと明示的に述べています。これにより、効果的にサードパーティコンポーネントのメンテナーになります。したがって、パッチを当てるのが良いアイデアかどうかは、目的の効果を確信できるようにコードを十分に理解しているかどうかだけに依存します。統合テストは、実際に想定どおりに動作していることを確認するのに十分なはずです。したがって、あなたが状況を伝えると、あなたの校閲者は間違っているように思えます。

誰もが費用、利益、リスクを負担できる限り、それを行うことには何の問題もありません。

...修正は十分に単純なようです...自分でコードにパッチを当てる

あなたが仕事をするとき、完璧な（まさにあなたが望むものであるサードパーティのライブラリを持っている）が十分な敵（あなた自身でそれをパッチする）であり、時にはあなたはそのようなことをしなければなりません。ベンダーがそれに到達する前に問題を修正できるように、商用ライブラリのソースライセンスを購入したプロジェクトを数多く行ってきました。

...中傷者は、これは危険であり、厄介な複雑さをもたらすという点で、ほとんど常に悪い考えだと主張します。

他の人のコードの分析、問題の特定、修正の作成を処理する機能がない場合は、悪い考えです。コードが社内であろうと第三者であろうと、それは事実です。唯一の違いは、膝に着地する前に、それがキュービクルまたは建物の壁の上に投げられたかどうかです。

批判者が、このパッチを適用しないことのコストを考慮せずに、単にアイデアを片付けている場合、彼らは宿題をしていません。パッチが修正するバグの影響を受ける社内コードが多数ある場合は、修正して問題を回避し、すべてを再テストして、正しく動作することを確認する必要があります。その後、パッケージをバグ修正バージョンにアップグレードした場合、回避策を見つけて削除し、再度テストする必要があります。同様に、変更したケースを見逃したり、テストが不十分だったりするなどのリスクがあります。個人的に、そのソースでバグを修正する機会があれば、ハエたたきで残りのコードを追いかけ、すべてを手に入れることを望んでいます。

...コードの変更は私たちによって行われました...それはコードベースの一部でなければなりません...新しいプロジェクトとして導入し、その自動ビルドをビルドプロセスに組み込む必要があります。

パッチを作成している場合、パッチは独自のコードの一部であるため、プロセスの一部にする必要があります。これは、システムに100％コードを追加することと何も変わりません。サードパーティのディストリビューションを神聖なものとして扱い、ソースコードと同じようにモジュールに入れます。作成したパッチは、個別のファイルに保存され、ビルドプロセスの一部として適用されます。そうすることで、常にクリーンなソースからパッチを適用したソース、ビルドされた製品に移行し、何が起こっているかを正確に示すことができます。（一部の人々は、バージョン管理でそれを解凍、ハンドパッチ、再パック、保存します。それは悪いことです。）

...私たちはソース管理リポジトリからコードを私たちのものに引っ張っていて、コード変更の背後にある歴史を失います...

サードパーティのライブラリをサードパーティの依存関係として扱っている場合、最初からその履歴はなく、何も失うことはありません。サードパーティのリポジトリに引き続きアクセスできる場合は、必要に応じて相談できます。サードパーティのリリースは、変更せずに独自のシステムにチェックインするアモルファスBLOBのように扱う必要があります。使用しているリリースとそれ以降のリリースとの間の変更を確認する必要がある場合は、それを行うことができ、必要に応じて、必要な変更を組み込んだ古いバージョンへのパッチを作成します。

また、実行する必要のあるこのような小さなコードの変更には、非常に複雑すぎるもののように思えます。

ビルドプロセスが十分に洗練されている場合、これを追加することは、独自のコードを追加することより難しくありません。unpack / patch / buildプロセスが自動で行われるようになるまでには少し手間がかかりますが、一度完了すると、それは永遠に行われます。現在1つのバグがあるかもしれませんが、将来20になる可能性があります。存在する場合は、次の19の作業をはるかに少なくするため、すべてを今すぐサポートするための基礎を築いた方がはるかに幸せになります。

あなたがしたいことは十分に理にかなっているように見えますが、それに反対するプロセスの理由があるように聞こえます。提案されたソリューションを比較するつもりはありませんが、おそらくケーキを食べて食べられる方法があるでしょう：

問題のオープンソースプロジェクトで許可されている場合は、バックポートされたバグ修正をリポジトリに提供してください。つまり、バージョン1.5.2を使用していて、現在の安定バージョンが1.6.1である場合、1.5.2へのパッチを提供します。採用されたら、リポジトリから直接（おそらくバージョン1.5.3として）固定ソースを取得して、全員を満足させることができます。

言い換えれば、あなたの状況にいる他のすべての人にもパッチを当ててください。もちろん、これは、プロジェクトがリリースバージョンへの更新をサポートしている（または少なくとも許可している）場合にのみ可能です。しかし、これは確かに最近のかなり標準的なプラクティスです。