Come procedere quando si sospetta un errore nelle librerie open source?

Di solito provo quanto segue, nell'ordine:

1) Controlla la mailing list o i forum per vedere se il mio bug è nuovo, è già sul tracker, o è corretto in una versione più recente / SVN / qualunque sia

2) Se il bug non è noto, chiedi informazioni nella mailing list. Questo è quando ti viene detto che è una funzionalità, non un bug e / o RTFM;)

3) Se il bug è davvero un bug ed è nuovo, puoi aspettare fino a quando qualcuno lo risolve (puoi aiutare fornendo ulteriori informazioni, test o debug) o correggerlo da solo e inviare una patch

Se hai bisogno che il bug sia risolto con urgenza, la soluzione migliore è fare i passaggi 2 e 3 insieme (segnalare il bug e proporre una patch). Altrimenti il tuo bug potrebbe essere riparato o meno in modo tempestivo, a seconda che qualcuno ritenga che valga la pena ripararlo. Immagino che tu possa "corrompere" gli sviluppatori o altri membri della comunità per lavorare sul tuo bug, anche se non l'ho mai provato.

Il bello di OSS è che hai il codice sorgente!

Quindi puoi apportare da te la correzione o assumere qualcuno per farlo.

L'importante è restituire alla community e controllare la tua correzione!

Il modo più sensato che ho trovato, quando hai un problema con una biblioteca e non hai le capacità per trovare da soli il problema, è contattare i manutentori. Conoscono il codice e saranno grati di scoprire i bug, se è quello che sono, o ti indicheranno come utilizzare correttamente la libreria.

Ad esempio, ho riscontrato un problema che non riuscivo a risolvere quando stavo sviluppando un sito che utilizzava SVG Web . Non ho alcuna capacità di scripting di azioni, quindi ho iniziato a chiedere un thread riguardo il problema e mi è stato detto di registrare un bug con un caso di test minimale, quindi l'ho fatto. Si è scoperto che il problema era nel browser, quindi ho dovuto modificare leggermente il mio codice.

Se sei abbastanza intelligente da risolvere da solo, non dimenticare di restituire ciò che hai imparato.

Se hai una buona idea di come riprodurre il bug, allora scrivere un test unitario esponendo il bug sarebbe un buon punto di partenza. (Spesso i progetti open source hanno già suite di test di grandi dimensioni).

Il test dell'unità fallito è un buon modo per comunicare il "bug" al manutentore del progetto. Se non si tratta di un bug ma semplicemente di te che lo stai usando in modo errato, il maintainer vorrebbe far notare che questo è di progettazione, e molto spesso con una motivazione.

Scrivi un caso di test pulito, quindi invialo alla mailing list.

IME il più delle volte trovi un errore nel tuo codice mentre scrivi il test case.

Solo perché non è stato ancora menzionato, dai " Come fare domande in modo intelligente "una lettura. Ha molti consigli inestimabili su come affrontare le domande e chiedere aiuto a una comunità di sviluppo. Molto si riduce a: capire come funziona la community e assicurarsi di giocare secondo le regole. Se sei rispettoso, fai una domanda intelligente fornendo tutti i dettagli necessari (e la ricetta di riproduzione se è un possibile bug), probabilmente otterrai una risposta ragionevole.