La patch di software open source durante l'aggiornamento non è un'opzione?

13

Recentemente mi sono imbattuto in un bug piuttosto fastidioso (confermato) in un pacchetto software open source che ho integrato nella mia applicazione. Secondo il tracker di problemi pubblici questo bug è stato risolto nell'ultima versione del software.

A volte è necessario che la correzione di errori per evitare un refactoring costoso di un particolare modulo, tuttavia, per ragioni tecniche e / o politiche, non sarà possibile eseguire l'aggiornamento all'ultima versione.

Ispezionando le modifiche apportate al codice, la correzione sembra abbastanza semplice da ritenere che un'opzione praticabile sia quella di ricalcolare il codice da solo e ricompilare la versione del software attualmente approvata, tuttavia i detrattori sostengono che questo è quasi sempre una cattiva idea in quanto è rischiosa e introduce una complessità fastidiosa.

Ai loro occhi perché questo cambiamento di codice è stato fatto da noi esclusivamente per il nostro uso, deve far parte della nostra base di codice, il che significa che piuttosto che introdurre il software open source come dipendenza di terze parti, dobbiamo introdurlo come una nuova progetto e incorporare la sua build automatizzata nel nostro processo di costruzione.

Per quanto mi riguarda, penso che questo sia sbagliato, dato che dovremmo estrarre il codice dal loro repository di controllo del codice sorgente nel nostro, e perdiamo la cronologia dietro le modifiche al codice precedenti. Inoltre sembra proprio qualcosa che è troppo complicato per una modifica così piccola del codice che deve essere fatta.

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

    
posta maple_shaft 22.02.2013 - 13:55
fonte

4 risposte

12

Se non puoi utilizzare una versione successiva che non ha il problema che stai incontrando, le uniche opzioni disponibili sono

  • convivi con il problema e trova una soluzione alternativa
  • inserisci la libreria e risolvila nella tua versione privata (che è ciò che faresti effettivamente)
  • getta la spugna e informa i tuoi dirigenti che il problema è insormontabile (il che sarebbe una bugia, visto che hai altre due opzioni a tua disposizione).


Sono stato nella tua posizione, l'opzione 2 (creare una forcella personalizzata) è spesso la soluzione più appetibile disponibile. Questa è la vita quando si ha a che fare con le librerie open source, specialmente quelle che evolvono rapidamente e hanno la cattiva abitudine di rompere la retrocompatibilità tra le versioni (che nella mia esperienza è la ragione più comune per dover fare cose del genere).
Per più di alcune librerie OSS, ho guidato me e i team di cui ho fatto parte per imporre wrapper in tutto e tutti e accedere alla funzionalità di librerie di terze parti esclusivamente attraverso questi wrapper. In questo modo, se abbiamo bisogno di sostituire una libreria di terze parti con una versione così diversa da infrangere il nostro codice, le modifiche sono almeno in gran parte limitate a quel wrapper. Non è il più bello (aggiunge il codice, può aggiungere complessità e costi) ma a volte è l'unico modo per mantenere il buonsenso.

    
risposta data 22.02.2013 - 14:31
fonte
6

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

Tuttavia, hai detto esplicitamente che non aggiornerai il codice in bundle. Questo ti rende effettivamente il manutentore del componente di terze parti. Pertanto, il fatto di applicarlo in patch è una buona idea o meno dipende solo dal fatto che capisci quel codice abbastanza bene da essere sicuro dell'effetto desiderato. I test di integrazione dovrebbero essere sufficienti per verificare che sia, in effetti, facendo ciò che si assume. Pertanto, mentre comunichi la situazione, mi sembra che i revisori abbiano torto.

    
risposta data 22.02.2013 - 14:22
fonte
3

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

...the fix seems simple enough ... to patch the code myself

Quando hai un lavoro da fare, perfetto (avere una libreria di terze parti che è esattamente ciò che vuoi) è il nemico di abbastanza buono (aggiustandolo tu stesso), ea volte devi fare cose del genere. Ho realizzato diversi progetti in cui abbiamo acquistato licenze di origine per le librerie commerciali in modo da poter risolvere i problemi prima che il fornitore ci arrivasse.

...detractors want to argue the case that this is nearly always a bad idea in that it is risky and introducing a troublesome complexity.

È una cattiva idea se non hai le costole per gestire sezionare il codice di qualcun altro, identificare un problema e scrivere una correzione. È vero che il codice è in-house o di terze parti; l'unica differenza è se è stato gettato sopra un cubicolo o un muro dell'edificio prima che cadesse in grembo.

Se i tuoi detrattori stanno semplicemente spazzando via l'idea senza pesare i costi di non facendo questa patch, non stanno facendo i compiti. Se hai un sacco di codice in-house che è influenzato dall'errore che la tua patch potrebbe risolvere, dovrai passare e cambiarlo per aggirare il problema e rieseguire il test di tutto per assicurarti che funzioni correttamente. Quindi, se dovessi aggiornare il pacchetto a una versione corretta, potresti dover trovare e rimuovere i tuoi workaround e ripetere il test. Vi sono anche dei rischi, come mancare un caso che hai modificato o un test insufficiente. Personalmente, se avessi l'opportunità di correggere un bug alla fonte, preferirei farlo lì piuttosto che inseguire il resto del codice con uno scacciamosche e spero di ottenere tutto.

...code change was done by us ... it must be part of our code base ...we must introduce it as a new project and incorporate its automated build into our build process.

Se stai facendo una patch, la patch fa parte del tuo codice, il che significa che devi renderlo parte del tuo processo. Questo non è diverso dall'aggiunta di qualcosa che è al 100% il tuo codice al tuo sistema. Considera sacrosanta la distribuzione di terze parti e inseriscila in un modulo come se fosse un codice sorgente. Tutte le patch che scrivi sono memorizzate con esso in file separati e applicate come parte del processo di compilazione. In questo modo vai sempre da fonte pulita a fonte patchata a prodotto costruito e puoi mostrare esattamente cosa sta succedendo. (Alcune persone decomprimono, applicano le patch a mano, reimballano e archiviano ciò nel controllo di versione.).

...we would be pulling their code from their source control repository into ours, and we lose the history behind any code changes...

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 si continua ad accedere al repository di terze parti, è possibile consultarlo qualora fosse necessario. I rilasci di terze parti dovrebbero essere trattati come blob amorfi che controlli nel tuo sistema inalterato. Se hai bisogno di guardare le modifiche tra il rilascio che stai utilizzando e le versioni successive, puoi farlo e, se lo desideri, fornire le patch alla vecchia versione che incorporano le modifiche che desideri.

Also it just seems like something that is far too complicated for such a small code change that needs to be made.

Se il tuo processo di compilazione è sufficientemente sofisticato, aggiungere questo non dovrebbe essere più difficile dell'aggiunta del tuo codice. C'è un po 'di fatica nel portarlo al punto in cui il processo di decompressione / patch / build è automatico, ma una volta finito, è fatto per sempre. Potrebbe esserci un bug adesso, ma ce ne potrebbero essere venti in futuro. Se ci sono, sarai molto più felice di aver gettato le basi per sostenere tutto questo ora, perché renderà il lavoro con i prossimi 19 molto meno lavoro.

    
risposta data 22.02.2013 - 15:00
fonte
2

Quello che vuoi fare sembra abbastanza ragionevole, ma sembra che ci siano (buoni?) motivi per opporsi. 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, contribuisci con il tuo bugfix back-back al loro repository. Cioè, se stai usando la versione 1.5.2 e la versione stabile corrente è la 1.6.1, contribuisci con una patch alla 1.5.2. Se viene adottato, puoi recuperare la fonte fissa direttamente dal repository (forse come versione 1.5.3) e rendere tutti felici.

In altre parole: applicalo a tutti gli altri che si trovano nella tua situazione. Naturalmente questo è possibile solo se il progetto supporta (o almeno consente) aggiornamenti alle versioni rilasciate. Ma di sicuro è una pratica abbastanza normale in questi giorni.

    
risposta data 22.02.2013 - 17:28
fonte

Leggi altre domande sui tag