Patching del software open source quando l'aggiornamento non è un'opzione?

Di recente ho riscontrato un fastidioso (confermato) bug in un pacchetto software open source che ho integrato nella mia applicazione. Secondo il tracker dei problemi pubblici, questo bug è stato risolto nell'ultima versione del software.

Di tanto in tanto AVETE BISOGNO di quella correzione di bug per evitare un costoso refactor di un particolare modulo, tuttavia per motivi tecnici e / o politici, non sarete in grado di aggiornare all'ultima versione.

Sull'ispezione delle modifiche apportate al codice, la correzione sembra abbastanza semplice che ritengo che un'opzione praticabile sarebbe quella di correggere il codice da solo e ricompilare la mia attuale versione approvata del software, tuttavia i detrattori vogliono argomentare che questa è quasi sempre una cattiva idea in quanto è rischioso e introduce una complessità fastidiosa.

Ai loro occhi perché questa modifica del codice è stata fatta da noi esclusivamente per il nostro uso, deve far parte della nostra base di codice, nel senso che anziché introdurre il software open source come dipendenza di terze parti, dobbiamo introdurlo come nuovo progetto e incorporarlo la sua compilazione automatizzata nel nostro processo di compilazione.

Per me penso che sia sbagliato, dato che estrarremmo il loro codice dal loro repository di controllo del codice sorgente nel nostro, e perdiamo la storia dietro eventuali modifiche al codice precedenti. Inoltre sembra solo qualcosa di troppo complicato per una modifica del codice così piccola che deve essere fatta.

In questo caso sarebbe una cattiva idea fare quanto sopra? In tal caso, qual è la situazione ideale quando l'open source deve cambiare, ma solo per il tuo unico vantaggio in casa?

Se non puoi utilizzare una versione successiva che non presenta il problema che stai riscontrando, le uniche opzioni che hai sono sono

• convivere con il problema e trovare una soluzione alternativa
• fork la libreria e risolverlo nella tua versione privata (che è quello che avresti effettivamente fatto)
• getta la spugna e dì ai tuoi manager che il problema è insormontabile (il che sarebbe una bugia, dato che hai altre due opzioni aperte).

Sono stato nella tua posizione, l'opzione 2 (crea una forcella personalizzata) è spesso la soluzione più appetibile disponibile. Questa è la vita quando si ha a che fare con le librerie open source, in particolare quelle che si evolvono rapidamente e hanno la cattiva abitudine di rompere la compatibilità all'indietro tra le versioni (che nella mia esperienza è il motivo più comune per fare cose del genere).
Per più di alcune librerie OSS mi ha portato e team a cui ho fatto parte per incaricare i wrapper attorno a tutti loro e accedere alla funzionalità delle librerie di terze parti esclusivamente tramite tali wrapper. In questo modo, se dobbiamo sostituire una libreria di terze parti con una versione così diversa da rompere il nostro codice, le modifiche sono almeno in gran parte confinate a quel wrapper. Non è il migliore (aggiunge il codice, può aggiungere complessità e prestazioni in termini di costi) ma a volte è l'unico modo per mantenere la sanità mentale.

Quello che stai per fare è una cattiva idea nel caso più comune in cui si raggruppano software di terze parti e si intende monitorare le loro versioni . Di solito le persone lo fanno perché desiderano una funzionalità nel componente di terze parti che i manutentori non sono disposti a implementare o implementare nel modo in cui è necessario.

Tuttavia, hai esplicitamente dichiarato che non aggiornerai il codice in bundle. Ciò ti rende efficacemente il manutentore del componente di terze parti. Pertanto, se l'applicazione di patch è una buona idea o meno dipende solo dal fatto di aver compreso quel codice abbastanza bene da essere sicuro dell'effetto desiderato. I test di integrazione dovrebbero essere sufficienti per verificare che, di fatto, stia facendo ciò che si presume. Pertanto, mentre dici la situazione, mi sembra che i tuoi recensori abbiano torto.

Non c'è davvero nulla di sbagliato nel farlo finché tutti possono sostenere costi, benefici e rischi.

... la correzione sembra abbastanza semplice ... per correggere il codice da solo

Quando hai un lavoro da fare, perfetto (avere una biblioteca di terze parti che è esattamente quello che vuoi) è il nemico del abbastanza buono (rattoppandolo da solo), e talvolta devi fare cose del genere. Ho realizzato una serie di progetti in cui abbiamo acquistato licenze di origine per biblioteche commerciali in modo da poter risolvere i problemi prima che il fornitore ci arrivasse.

... i detrattori vogliono sostenere il fatto che questa è quasi sempre una cattiva idea in quanto è rischiosa e introduce una complessità fastidiosa.

È una cattiva idea se non hai le braciole per gestire sezionare il codice di qualcun altro, identificare un problema e scrivere una correzione. Questo è vero se il codice è interno o di terze parti; l'unica differenza è se è stato gettato sopra un cubicolo o costruendo un muro prima di atterrare in grembo.

Se i tuoi detrattori stanno semplicemente spazzando via l'idea senza soppesare i costi di non fare questa patch, non stanno facendo i compiti. Se hai un sacco di codice interno che è interessato dal bug che la tua patch correggerebbe, dovrai attraversarlo e cambiarlo per aggirare e testare nuovamente tutto per essere sicuro che funzioni correttamente. Quindi, se dovessi mai aggiornare il pacchetto a una versione corretta, potresti dover trovare e rimuovere le soluzioni alternative e ripetere il test. Ci sono anche rischi nel farlo, come perdere un caso modificato o test insufficienti. Personalmente, se ho l'opportunità di correggere un bug alla sua fonte, preferirei farlo lì piuttosto che inseguire il resto del codice con un flyswatter e spero di ottenere tutto.

... la modifica del codice è stata fatta da noi ... deve far parte della nostra base di codice ... dobbiamo introdurlo come nuovo progetto e incorporare la sua build automatizzata nel nostro processo di compilazione.

Se stai eseguendo una patch, la patch fa parte del tuo codice, il che significa che devi renderlo parte del tuo processo. Questo non è diverso dall'aggiungere qualcosa che è al 100% il tuo codice al tuo sistema. Tratta la distribuzione di terze parti come sacrosanta e inseriscila in un modulo proprio come se fosse un codice sorgente. Tutte le patch che scrivi vengono archiviate con esso in file separati e applicate come parte del processo di compilazione. In questo modo passi sempre da sorgente pulita a fonte patchata a prodotto costruito e puoi mostrare esattamente cosa sta succedendo. (Alcune persone disimballano, patch a mano, reimballano e memorizzano nel controllo della versione. È un male.)

... stiamo estraendo il loro codice dal loro repository di controllo del codice sorgente nel nostro e perdiamo la cronologia dietro eventuali modifiche al codice ...

Se stai trattando la libreria di terze parti come una dipendenza di terze parti, non hai quella storia per cominciare e non stai perdendo nulla. Se hai accesso continuo al repository di terze parti, puoi consultare ciò di cui hai bisogno. Le versioni di terze parti devono essere trattate come BLOB amorfi che si controllano inalterati nel proprio sistema. Se è necessario esaminare le modifiche tra la versione che si sta utilizzando e le versioni successive, è possibile farlo e, se lo si desidera, elaborare patch per la versione precedente che incorporano le modifiche desiderate.

Inoltre sembra solo qualcosa di troppo complicato per una modifica del codice così piccola che deve essere fatta.

Se il tuo processo di compilazione è sufficientemente sofisticato, aggiungere questo non dovrebbe essere più difficile dell'aggiunta del tuo codice. C'è una piccola quantità di lavoro nel portarlo al punto in cui il processo di decompressione / patch / build è automagico, ma una volta fatto, è fatto per sempre. Potrebbe esserci un bug ora, ma potrebbero essercene venti in futuro. Se ci sono, sarai molto più felice di aver gettato le basi per supportare tutto ciò ora, perché renderà molto più difficile gestire il prossimo 19.

Quello che vuoi fare sembra abbastanza ragionevole, ma sembra che ci siano (valide?) Ragioni di processo per opporvisi. Non confronterò le soluzioni proposte, ma forse c'è un modo in cui potresti avere la tua torta e mangiarla anche tu:

Se il progetto open source in questione lo consente, aggiungi il tuo bugfix con back-port al loro repository. Cioè, se stai usando la versione 1.5.2 e l'attuale versione stabile è 1.6.1, aggiungi una patch alla 1.5.2. Se viene adottato, è possibile recuperare l'origine fissa direttamente dal repository (forse come versione 1.5.3) e rendere tutti felici.

In altre parole: patch per tutti gli altri che si trovano nella tua situazione. Naturalmente questo è possibile solo se il progetto supporta (o almeno consente) gli aggiornamenti alle versioni rilasciate. Ma questa è sicuramente una pratica abbastanza standard in questi giorni.