私は最近、アプリケーションに統合したオープンソースソフトウェアパッケージで、かなり厄介な(確認された)バグに遭遇しました。パブリックイシュートラッカーによると、このバグはソフトウェアの最新リリースで解決されています。
特定のモジュールの高額なリファクタリングを回避するためにバグ修正が必要になる場合がありますが、技術的および/または政治的な理由により、最新リリースにアップグレードすることはできません。
行われたコードの変更を調べると、修正は十分に単純であるため、コードに自分でパッチを適用し、現在承認されているバージョンのソフトウェアを再コンパイルすることが実行可能なオプションであると感じますが、批判者はこれがほとんどの場合悪い考えであると主張したいと思いますそれは危険であり、厄介な複雑さをもたらすという点で。
彼らの目には、このコード変更は私たちが使用するためだけに行ったものであるため、コードベースの一部である必要があります。つまり、オープンソースソフトウェアをサードパーティの依存関係として導入するのではなく、新しいプロジェクトとして導入して組み込む必要があります。ビルドプロセスへの自動ビルド。
私には、これは間違っていると思います。ソース管理リポジトリからコードを取得しているためです。その前に行われたコード変更の背後にある履歴は失われます。また、このような小さなコード変更を行うには複雑すぎるように思われます。
この場合、上記を行うのは悪い考えでしょうか?もしそうなら、オープンソースを変更する必要があるが、あなたの唯一の利益のために理想的な状況は何ですか?
発生している問題がない新しいバージョンを使用できない場合は、次のいずれかを選択するしかありません。
私はあなたの立場にあります。オプション2(カスタムフォークを作成する)は、多くの場合、利用可能な最も口当たりの良いソリューションです。オープンソースライブラリ、特に急速に進化し、リリース間の下位互換性を壊す悪い習慣があるライブラリを扱うときの人生です(私の経験では、このようなことをしなければならない最も一般的な理由です)。
いくつかのOSSライブラリについて、私と私が参加しているチームは、それらすべてのラッパーを義務付け、それらのラッパーを介してのみサードパーティライブラリの機能にアクセスするようになりました。そうすれば、サードパーティのライブラリを、コードを壊すほど異なるバージョンに置き換える必要がある場合、変更は少なくともそのラッパーに限定されます。それは最高ではありませんが(コードを追加し、複雑さとコストパフォーマンスを追加する可能性があります)、時にはそれがあなたの正気を保つ唯一の方法です。
あなたがやろうとしていることは、サードパーティのソフトウェアをバンドルするより一般的なケースでは悪い考えですそしてそれらのリリースを追跡するつもりです。通常、メンテナーが実装したくない、または必要な方法で実装したくないサードパーティコンポーネントの機能を望んでいるため、人々はそれを行います。
ただし、バンドルされたコードをnotアップグレードすることを明示的に述べました。これにより、サードパーティコンポーネントのメンテナーを効果的にすることができます。したがって、パッチを当てることが良いかどうかは、そのコードを十分に理解して理解して、目的の効果を確信できるかどうかにのみ依存します。統合テストは、それが実際に想定したことを実行していることを確認するのに十分なはずです。したがって、あなたが状況を言うように、あなたの査読者は間違っているようです。
誰もがコスト、メリット、リスクを負うことができる限り、それを行うことに何の問題もない。
...修正は、コードを自分でパッチするのに十分簡単です...
あなたがやるべき仕事をしているとき、完全な(まさにあなたが望むものであるサードパーティのライブラリを持っている)は十分に良い(それを自分でパッチする)敵であり、時にはあなたはそのようなことをしなければならない。ベンダーが問題に到達する前に問題を修正できるように、商用ライブラリのソースライセンスを購入したプロジェクトをいくつか行ってきました。
...中傷者は、これがリスクを伴い、厄介な複雑さをもたらすという点で、ほとんど常に悪い考えであると主張します。
他人のコードを分析し、問題を特定し、修正を書くためのチョップがない場合は、悪い考えです。これは、コードが社内にあるかサードパーティにあるかに関係なく当てはまります。唯一の違いは、それがあなたの膝に着陸する前に、それがキュービクルまたは建物の壁の上に投げられたかどうかです。
批判者がnotのコストを考慮せずにアイデアを単純に無視している場合、彼らは宿題をしていません。パッチが修正するバグの影響を受ける社内コードがたくさんある場合は、それを回避するためにコードを調べて変更し、すべてを再テストして正しく機能することを確認する必要があります。その後、パッケージをバグ修正バージョンにアップグレードした場合は、回避策を見つけて削除し、再テストする必要があります。変更したケースを見逃したり、テストが不十分だったりするなど、これを行うことにもリスクがあります。個人的には、そのソースでバグを修正する機会があれば、ハエたたきでコードの残りの部分を追いかけてすべてを手に入れられることを願うよりも、そこでバグを修正したいです。
...コードの変更は私たちによって行われました...コードベースの一部である必要があります...新しいプロジェクトとして導入し、その自動ビルドをビルドプロセスに組み込む必要があります。
パッチを実行している場合、パッチは独自のコードの一部です。つまり、パッチをプロセスの一部にする必要があります。これは、100%コードをシステムに追加することと何ら変わりはありません。サードパーティのディストリビューションをsacrosanctとして扱い、ソースコードと同じようにモジュールに配置します。作成したパッチは別のファイルに保存され、ビルドプロセスの一部として適用されます。そうすれば、常にクリーンなソースからパッチを適用したソース、ビルドされた製品に移行し、何が起こっているのかを正確に示すことができます。 (一部の人々は、それをバージョン管理で解凍し、手でパッチし、再梱包して保管します。それは悪いことです。)
...彼らのコードをソース管理リポジトリから私たちのリポジトリにプルし、コード変更の背後にある歴史を失う...
サードパーティのライブラリをサードパーティの依存関係として扱う場合は、最初からその履歴はなく、何も失うことはありません。サードパーティのリポジトリに引き続きアクセスできる場合は、必要に応じて相談できます。サードパーティのリリースは、変更せずに独自のシステムにチェックインするアモルファスBLOBのように扱う必要があります。使用しているリリースとそれ以降のリリースの間の変更点を確認する必要がある場合は、それを行うことができます。必要に応じて、必要な変更を組み込んだ古いバージョンへのパッチを用意してください。
また、このような小さなコード変更を行うには複雑すぎるように思われます。
ビルドプロセスが十分に洗練されている場合、これを追加することは、独自のコードを追加することよりも難しくありません。 unpack/patch/buildプロセスがautomagicになるまでには少し手間がかかりますが、一度実行すると、永久に実行されます。現在1つのバグがあるかもしれませんが、将来は20になる可能性があります。ある場合は、次の19の作業を大幅に減らすことができるため、これをすべてサポートするための基礎を築いたことは、はるかに幸せです。
あなたがやりたいことは十分に合理的であるように思われますが、それに反対する(音?)プロセスの理由があるように思えます。私は提案された解決策を比較しませんが、おそらくあなたがあなたのケーキを持ってそれを食べることができる方法があります:
問題のオープンソースプロジェクトで許可されている場合は、バックポートされたバグ修正をリポジトリに提供してください。つまり、バージョン1.5.2を使用していて、現在の安定バージョンが1.6.1の場合は、1.5.2にパッチを提供してください。それが採用された場合、リポジトリから直接固定ソースをフェッチして(おそらくバージョン1.5.3として)、みんなを幸せにすることができます。
言い換えれば、あなたの状況にいる他のすべての人にもパッチを適用してください。もちろん、これはプロジェクトがリリースされたバージョンへの更新をサポートする(または少なくとも許可する)場合にのみ可能です。しかし、それは最近ではかなり標準的なやり方です。