Per patch (scimmia) o non per patch (scimmia), questa è la domanda

Question

Stavo parlando con un collega di un comportamento inaspettato/indesiderato di qualche pacchetto che usiamo. Sebbene esista una soluzione facile (o almeno una soluzione alternativa) da parte nostra senza alcun evidente effetto collaterale, ha fortemente consigliato di estendere il codice pertinente fissandolo con cura e postando la patch upstream, sperando di essere accettata ad un certo punto in futuro. Di fatto, manteniamo le patch contro versioni specifiche di diversi pacchetti che vengono applicati automaticamente su ogni nuova build. L'argomento principale è che questa è la cosa giusta da fare, al contrario di una "brutta" soluzione alternativa o di una fragile patch per scimmie. D'altra parte, preferisco la praticità rispetto alla purezza e la mia regola generale è che "nessuna patch"> "patch di scimmia"> "patch dura", almeno per qualcosa di diverso da una correzione di bug (critica).

Quindi mi chiedo se c'è un consenso su quando è meglio applicare patch (hard), patch di scimmia o semplicemente provare a lavorare su un pacchetto di terze parti che non fa esattamente ciò che si vorrebbe. Ha principalmente a che fare con il motivo della patch (ad esempio correggere un bug, modificare il comportamento, aggiungere funzionalità mancanti), il pacchetto dato (dimensioni, complessità, maturità, reattività dello sviluppatore), qualcos'altro o non ci sono regole generali e uno dovrebbe decidere caso per caso?

Answer 1

a mio parere:

Se sarebbe indicato '/ comportamento indesiderato inaspettato' = bug, quindi monkeypatching (o duckpunching)!.

Se si ritiene che si tratti di un bug nella lib, è logico applicare patch e spingere la patch a monte.

Se capisco che la definizione di 'aggirare' per aggiungere complessità alla tua app per compensare un comportamento di lib, dovrei dire che il monkeypatching è sicuramente un'idea migliore.

mio .2 pesos.

Answer 2

Bene, è il rischio classico contro il beneficio.

La patch è esente da rischi? e pesante in benefici? monkeypatch it. Se c'è un po 'di rischio, e solo un po' di vantaggio, non lo terrei d'occhio e basta inserire la correzione nel tipico processo di rilascio.

Answer 3

Patching è la "cosa giusta" da fare per un motivo: con software open source, se hai scoperto un bug reale, o hai bisogno di una funzionalità che sospetti che altri possano aver bisogno, patch e invio della patch a monte è un modo per restituire alla comunità e contribuire a rendere il software migliore, nel suo complesso. Se la patch è accettata, è un +1 gratuito per te o per la reputazione della tua azienda. Nessuno è mai stato triste perché aveva troppi esempi di codice open source utile che ha contribuito alla comunità sul proprio curriculum ...

Non è che facciamo sempre la cosa giusta, al momento, nelle trincee. Ma se avremo una discussione astratta sulle migliori pratiche, se sembra che il giusto ordine di precedenza sia "patch and submit"> soluzione intelligente> trovare un pacchetto che funzioni meglio> brutto monkeypatch ;-)

Answer 4

Un'unica informazione che ci manca è se il comportamento imprevisto che descrivi è un bug, puro e semplice, o se è un comportamento che alcuni consumatori del pacchetto vogliono.

Come è stato affermato da altri qui, è il compromesso tra rischio e impegno. Non posso fare affermazioni definite senza conoscere le tue circostanze specifiche.

Tuttavia, la mia sensazione istintiva è che patch e push up comporteranno meno rischi e sforzi a lungo termine, supponendo che pensiate che la vostra patch sarà accettata.Indipendentemente dal fatto che tu sia un patch o un monkeypatch, ne avrai un costo: ogni volta che aggiorni la versione del pacchetto che utilizzi, dovrai testare che la tua patch funzioni ancora, e possibilmente aggiornarla a seconda sui cambiamenti nel pacchetto. Con una patch dura, dovrai anche riapplicare la patch, ma ci sarà meno lavoro del test/dell'aggiornamento che dovrai fare con entrambe le opzioni, molto probabilmente.

Ci sono due vincite per le patch in questo scenario, come la vedo io.

Se ci si è dimenticati della patch durante l'aggiornamento, con una patch dura, la patch sparirà completamente, causando un errore catastrofico e visibile, molto probabilmente. Considerando che con una patch di scimmia, il tuo patch sarà ancora lì, ma non lo avresti testato ha ancora lo stesso effetto, che a mio parere è uno stato di cose molto più pericoloso di quello che mancava completamente alla patch hard.

L'altra vincita per l'hard patching è che, con una patch difficile, alla fine dovrebbe essere integrata nel pacchetto, e il costo scompare. Mentre una patch per scimmie si bloccherà all'infinito, fino a quando il problema non verrà risolto in modo indipendente.

Se il comportamento imprevisto è qualcosa che gli altri consumatori di pacchetti vogliono, e non semplicemente un bug, questo complica l'immagine che dipingo. In questo caso la soluzione di patch scimmia dovrebbe semplicemente rimuovere il comportamento. La patch difficile, tuttavia, dovrebbe mantenere il comportamento per chi lo desidera.

Questa analisi ignora gli eventuali obblighi morali che possono essere imposti ai mantenitori del pacchetto e ad altri consumatori.

Inoltre, sto filosoficamente contrario a l'intero concetto di scimmia patch, ma non è rilevante per questa discussione :-)