Ethsim2
(Ethan )
25
まだこのPRについて目に見える進展はありません：
別々にメンテナンスするのではなく、この機能がバンドルされたEventsプラグインに実装されることを引き続き期待しています。
この以前の経験も、これを長期間ローカルでメンテナンスすることに少し慎重になっている理由です。
私のセルフホスト環境では、すでに小さなアップストリームのPRバックポートのためにafter_codeフックを使用しています。このフックはまず、その機能がアップストリームに反映されたことを示すマーカーを確認します。反映されていなければ、既知のコミットのパッチをダウンロードし、git apply --checkを実行してから、git applyで適用します。
パッチがコアと一致し続ける間は比較的うまく機能しますが、コアが進化したことで、そのバックポートの以前のバージョンが適用できなくなったことがすでにあります。その際、再構築が失敗し、フックを削除するまでコンテナがオフラインのままになっていました。
この特定の変更について、一時的なフォールバックが必要であれば、別のプラグインとしてパッケージングするのではなく、同様の方法でafter_codeバックポートを提供するでしょう。
その理由は、#43187がすでにバンドルされたEventsプラグイン自身のスケジュールされたサーバーサイドのローラーオーバーパスを変更しているためです。after_codeフックは、再構築中にほぼ同じアップストリームのパッチを直接適用できます。一方、別のプラグインであれば、拡張ポイントを通じてその統合を再作成するか、内部的なMonitorEventDatesの動作をプリペンド/オーバーライドする必要があり、これはもう1つのレイヤーを追加し、同様に脆くなる可能性があります。
after_codeアプローチのデメリットは、依然としてアップストリームのコードの正確な形状に依存していることです。後継トピックの動作がMonitorEventDatesに関わるため、git apply --checkが成功する限り、同じ固定コミットのパッチを继续使用できます。しかし、アップストリームがそのコードを十分に変更してパッチコンテキストが一致しなくなれば、変更を現在のmainにリベースまたは適応させ、新しいコミットを作成し、その新しいコミットSHAを使用するようにフックを更新する必要があります。
したがって、私の優先順位は以下のままです：
- 後継機能をバンドルされたEventsプラグインにマージする；または
- チームが外部に保つことを望む場合、繰り返しイベントのローラーオーバー周りにサポートされたフックを公開する。
それまで、after_codeパッチは実用的な一時的なセルフホストフォールバックですが、理想的な長期的な配布メカニズムとはみなしません。
「いいね！」 1