Di chi è la responsabilità di una correzione di bug?

Una situazione che si è presentata più volte in progetti open source è questa:

1. Ho notato un bug nella nostra distribuzione e ho scoperto una rapida patch di hacking. (Ad esempio, semplicemente commentando il codice che in realtà non è necessario.)
2. Dedico un po 'di sforzo extra per capire il vero bug, trovare una patch e inviarlo tramite una richiesta pull di Git o simili.
3. La mia richiesta pull è stata respinta. Forse la patch era imperfetta (es. Linee incluse che non avrebbe dovuto avere), forse violava lo stile di codifica, forse aveva altre ramificazioni. O forse ho fatto qualcosa di sbagliato in Git: la richiesta pull avrebbe dovuto essere riformata o qualcosa del genere. Un manutentore fornisce feedback su come migliorare la patch e richiede di inviarlo nuovamente.

A questo punto sono confuso su quanto dovrei procedere. Per quanto mi riguarda, non ho problemi: l'ho risolto nel passaggio 1. Ho segnalato il problema, ho persino preso provvedimenti per risolverlo per gli altri. Ma non credo che sia la "mia" richiesta pull, quindi non sento che la responsabilità di migliorare la patch dovrebbe venire da me.

Una situazione particolare che mi infastidisce è dopo la discussione sui fallimenti della mia patch, raggiungiamo un accordo su una mailing list su quale sarebbe la patch corretta (cioè, come dovrebbe comportarsi, a volte includendo ogni riga di codice spiegata). Quindi, si presume che sia ancora mia responsabilità generare e inviare effettivamente la patch.

Esiste un'etichetta standard in queste situazioni? Come vengono risolti? La mia reazione è insolita? Fino a che punto ci si aspetta che venga accettata la correzione dei bug?

(Nota quando dico "progetto open source", alcuni di questi sono molto piccoli, ma potrebbero non essere hobby - semplicemente piccoli progetti software che sono utili a diverse organizzazioni, che impegnano le risorse degli sviluppatori a lavorare su di essi. Nel caso la risposta ovvia è "correggi la patch e reinvia", capisci che ho delle responsabilità nei confronti del mio datore di lavoro per lavorare su cose che sono di beneficio per loro. Trascorrere del tempo a riparare un bug che non ci riguarda sarebbe sbagliato ...)

Per quanto mi riguarda, se trovi un bug o hai una richiesta di miglioramento, non contribuisci al progetto e hai inviato un rapporto sui difetti attraverso i canali appropriati, hai finito. In termini di restituzione alla comunità, chiunque stia utilizzando un progetto open source e trova un difetto dovrebbe segnalarlo.

Il tentativo di trovare una soluzione, progettarla e implementarla è un vantaggio per il progetto. Se lo hai fatto, potrebbe essere una buona idea inviarlo, tramite una richiesta pull o magari inviando delta di file al team di sviluppo insieme al rapporto sui difetti o alla richiesta di miglioramento per dare loro qualcosa su cui lavorare. Tuttavia, non hanno l'obbligo di accettare il tuo contributo al progetto.

Aspettarsi che un utente contribuisca con le patch mi sembra sbagliato. È abbastanza facile partecipare a una discussione su un problema, ma è un investimento di tempo molto più grande trovare una soluzione. Nessun progetto dovrebbe aspettarsi che chi non contribuisce diventi un collaboratore solo per risolvere un singolo problema.

Procedi nella misura in cui sei disposto a tollerarlo. Sarebbe bello sistemare la patch e condividerla con il mondo nel trunk principale, ma se il manutentore non la desidera, scrollare le spalle. Puoi pubblicare da qualche parte il tuo problema e la patch per risolverlo, in modo che altri nella stessa barca possano cercare una soluzione.

E non sei senza problemi. La tua patch non sarà nel prossimo aggiornamento. Quindi dovrai riprovare e spero che funzioni o massaggiarlo in posizione, ogni volta che prendi una nuova versione. Quindi entrare nel progetto principale farà risparmiare tempo e tempo a te e alla tua azienda.

È un dolore per te, ma stai contribuendo alla comunità. Sicuramente apprezzo tutto il contributo del lavoro svolto. Non è come un software di qualità che magicamente è solo una genesi delle masse. Qualcuno deve fare il lavoro. (Quindi chi è fantastico? Sei fantastico). Se non ti senti all'altezza, annuncia alla community che, mentre apprezzi la discussione su come dovrebbe essere, sei semplicemente troppo occupato per farlo. Voglio dire, cosa faranno? Tagliare i tuoi salari?

C'è un principio che semplifica la comprensione della cultura open source: la persona che svolge il lavoro decide su cosa lavorare. Questo è uno dei suoi appelli rispetto ai lavori diurni degli sviluppatori. La tua priorità numero 1 potrebbe essere # 50 sul loro portafoglio ordini. Se non risolvi la tua richiesta pull, probabilmente finirà per arrivare all'inizio e loro se ne occuperanno. Tuttavia, se lo rendi abbastanza facile per loro, ora se ne occuperanno.

L'altro motivo per cui ti chiedono di correggere la tua richiesta pull è più magnanimo. Vogliono che tu ottenga credito per il tuo contributo, per quanto piccolo possa essere. Se esegui la correzione, il tuo nome è quello nel campo dell'autore del commit. Molte persone sono abbastanza orgogliose del loro contributo per volerlo vedere, quindi il modus operandi predefinito dei manutentori è lasciarlo.

Per quanto riguarda la tua responsabilità nei confronti del tuo datore di lavoro, se la tua azienda si affida a questo codice non stai facendo loro un disservizio. I datori di lavoro conoscono il vantaggio di un lavoratore che impiega tempo per affinare i suoi strumenti.

AFAIK, il modo open source è che la responsabilità di correggere i bug è lasciata a chi si preoccupa abbastanza del bug per gestire l'onere da garantire che sia corretto. A seconda delle circostanze, ho fatto di tutto, semplicemente ignorando un problema, combattendo (fornendo patch e argomentando affinché fossero accettate) per assicurarmi che fosse risolto.

Va tutto bene, non lasciare che le persone che gestiscono il progetto si aspettino da te la cosa sbagliata (cioè dai loro la speranza che risolverai correttamente il problema con le opzioni di discussione e poi non faranno nulla), probabilmente sono a conoscenza di più problemi di loro riescono a gestirsi da soli e cercheranno di fornirti un contributo ricorrente, se possibile.

Il bug originale può interessare solo te, quindi è nel tuo interesse ottenere l'invio facendo tutto ciò che è necessario per rendere la tua patch conforme. Altrimenti la prossima versione che tirerai (perché hai bisogno di altre correzioni) mancherà la tua correzione.

Non si desidera mantenere un elenco di patch che è necessario applicare ogni volta che si estrae una nuova copia del progetto: è solo un problema. Prenditi un po 'di tempo extra e riparalo permanentemente in modo da non doverlo più affrontare.

A uno sviluppatore open source, ci sono due tipi di problemi:

• (a) problemi senza patch
• (b) problemi causati da una patch

Penso che la maggior parte dei manutentori / sviluppatori di pacchetti open source ADORO l'idea di aiutare ad ottenere un contributore non core aggiornato con le loro patch.

Il loro obiettivo principale, tuttavia, è ridurre al minimo il numero di problemi di tipo b. Ecco perché il bar è piuttosto alto.

Alcune persone lo superano. Diventano collaboratori o forse anche collaboratori principali. Altri si arrendono. C'è una certa natura darwiniana nell'Open Source: la sopravvivenza del più adatto.

Ti incoraggio a insistere e sputare il tuo contributo al punto in cui il team lo accetta. Dopo aver apportato alcuni contributi, si fideranno ulteriormente di te, ma dovresti comunque assicurarti che i tuoi contributi siano impeccabili.

Ne vale la pena il risultato finale. Roba come poter dire "Devo programmare? Sì ... Stai eseguendo qualcosa che ho scritto, ogni giorno."