Come iniziare a correggere i bug nel software open source?

Ecco un suggerimento:
Richieste di funzioni: usa "sposta" "invece di" copia "dalla cartella temporanea - ID: 1615140

Can you change behaviour of 7-zip to use "move" instead of "copy" when 7-zip unzips the files. Issue is with single HDD systems and big files, this will speed up things significantly. WinRAR does it right now.

E spiegherò perché prendo questo bug come esempio.

Prima di decidere di scegliere questo progetto ...

• Ti senti a tuo agio con il codice sorgente di questo progetto?
  • Riesci a capire sia il codice C (principalmente gli algoritmi di compressione core)?
  • E anche il codice C ++ (la maggior parte delle "applicazioni", la GUI e la riga di comando, e anche tutte le interazioni con i sistemi operativi)?
  • E anche lo stile di codifica (tipico della programmazione Win32, non usando MFC / ATL)?
• Investirai tempo e sforzi in questo sistema operativo?
  • È necessaria una buona conoscenza dell'API di Windows.
  • Ad esempio: Windows funzioni API di gestione file .

Primo passo: puoi riprodurre il bug?

• Per scegliere un bug su cui lavorare, è necessario essere in grado di riprodurre il problema in un ambiente informatico simile.
  • Questo bug richiede di testare su un computer che (1) la cartella temp ha spazio libero basso (1-2 GB), (2) la destinazione di estrazione si trova sulla stessa unità della cartella temp .
• Quanto tempo è necessario per "configurare" l'ambiente per riprodurlo?
  • Scegli bug facili da riprodurre e facili da correggere.
• Il bug è davvero un bug?
  • Cerca sempre di riprodurlo da solo. Non fare affidamento solo sulle parole di altri.
  • Come programmatore / programmatore di software, vedi se riesci a spiegare il comportamento del bug in termini di comprensione. A volte gli utenti hanno aspettative non realistiche su come funzionano i sistemi software / hardware e rendono impossibili richieste di funzionalità.
• Come posso confermare la mia comprensione? Come faccio a sapere se è copiare o spostare il file?
  • Avrai bisogno di strumenti diagnostici, come Process Monitor . Puoi anche modificare la configurazione della tua macchina di prova per testare diversi scenari.

Secondo passaggio: puoi individuare il codice responsabile di questo comportamento?

• È necessaria una comprensione generale approssimativa del progetto, in base a risposta di Larry Coleman .
• È meglio se hai Visual Studio (un ambiente di sviluppo integrato e un debugger) in modo che tu possa impostare i breakpoint e capire il flusso del programma.

Terzo passo: apporta modifiche e osserva come influisce sul comportamento del programma.

Quarto passaggio: presenta le modifiche ai tuoi colleghi / colleghi e ottieni feedback.

Correggere i bug potrebbe non essere la cosa più facile. È più facile che aggiungere nuove funzionalità, ovviamente. Ma ancora più semplice è aggiornare la documentazione o testare una nuova versione. Entrambe ti faranno acquisire familiarità con il codice in modo da poterne conoscere abbastanza da correggere un bug. Dà anche l'apprendimento del codice un senso di scopo che aiuta gli altri.

Secondo me, una cosa molto importante a cui molte persone che hanno l'ambizione di contribuire alle persone dell'open source, è communication con gli altri sviluppatori sul progetto open source.

Se vuoi contribuire a un progetto open source, la prima cosa da fare è seguire ciò che sta accadendo nel progetto. Se c'è una mailing list, forum, Google Group o altro modo in cui gli sviluppatori comunicano, unisciti a loro. Scopri quali contributi sono maggiormente necessari. Fai domande su come funziona il software, ecc.

Se scarichi il codice sorgente, prova a capirlo da solo, quindi ti costerà molto più tempo. Se aggiusti qualcosa o aggiungi una nuova funzione e la offri improvvisamente, è meno probabile che venga accettata.

Quindi, parla con gli altri sviluppatori, scopri quali sono i bug con la priorità più alta o le funzionalità mancanti, ecc.

I have even gone through some files in the source code which I downloaded but didn't understood anything.

Questo è il primo bug che dovresti correggere. Devi capire la base del codice prima di iniziare a correggere i bug. Altrimenti, come farai a sapere se le tue correzioni infrangeranno qualcos'altro?

Ci sono diversi metodi per familiarizzare con il codice in un progetto a cui stai partecipando. Il mio metodo preferito è quello di leggere tutto il codice una volta, quindi tornare indietro e guardare le sezioni più in dettaglio.