Modifica di un'applicazione open source

Qual è il flusso di lavoro generale quando desidero aggiungere una funzione a un'applicazione open source che non avevo originariamente scritto? Come faccio a conoscere il codice? Come trovo il punto che deve essere modificato o aggiunto? Come posso effettivamente apportare la modifica senza interrompere nient'altro? Come posso verificare che tutto funzioni ancora?
Quali sono le linee guida generali su un tale progetto?

open-source

— Dani
fonte

È inoltre necessario inviare le modifiche al progetto, in genere come patch, in modo che altri possano trarne vantaggio.

C'è un protocollo, tutti lo desume più o meno con il tempo, ma eccolo, srotolato.

Si scarica la fonte distribuita.
Inizi a navigare un po 'nel codice da solo
- Se è un programma compilato, impari ora come compilarlo.
- In caso di mancata compilazione, riferisci all'autore / alla mailing list e chiedi indicazioni
Se non capisci davvero nulla del codice ...
- Beh, no, non glielo chiedi quasi.
- Lo lasci cadere, poiché probabilmente non sei all'altezza e non può essere di alcun aiuto reale.
- Invii una funzione se l'autore / i accetta richieste di funzionalità.
Altro
- Trova il punto che vuoi cambiare.
- Se ti chiedi qualche dettaglio minore, chiedi all'autore / alla mailing list e spieghi le tue intenzioni.
- Si esegue il cd nella directory principale della distribuzione (quella in alto che esce dal untarring / unzipping)
- voi diff -ur . > mypatch.path
- Mandi mypatch.patchall'autore spiegando cosa hai fatto, perché l'hai fatto e (dato che sei già lì) dichiari chiaramente di rinunciare a loro i diritti sulla patch.
se gli autori non gradiscono il tuo contributo
- controlli se esiste un modo per rilasciare la modifica come plug-in di qualche tipo
  - in tal caso, ora sei sulla buona strada per diventare un gestore di plugin .
- altro
  - ti infastidisci sulla situazione sul tuo blog e rilasci la patch lì, scaricabile gratuitamente e prova con la tua spiegazione e i tuoi sfoghi,
  - perseguiti di tanto in tanto il sistema di bug / la mailing list cercando di acquistare il supporto per la tua patch. Evita di essere bandito.
- in nessuno di questi casi si biforca il codice , poiché è un processo molto stancante e poco gratificante che difficilmente sarà in grado di tenere il passo con il tempo: ciò lascerà gli utenti tristi e confusi. Forks dovrebbe davvero accadere solo quando una grande società sta cercando di opprimere le sue decisioni su un pezzo di OSS .
altro
- ricevi ulteriori istruzioni da quell'autore / i

Sul lato: c'è una recente alternativa alla diff -ur .patch ed è il modo github .

"Fork" il loro codice su github sotto il tuo nome,
(ora hai una copia del loro codice sul tuo account)
collega il tuo git a quella tua copia personale,
apporta le tue modifiche su di esso, archiviali,
e dì all'autore o agli autori principali di guardare al tuo progetto github.
Se gli piace, sincronizzeranno .
Altrimenti, puoi collegare il tuo "gitfork" sul tuo blog.

— ZJR
fonte

Va bene fino a quando non suggerisci che l'OP fiammeggia gli autori del prodotto per non aver abbracciato la nuova patch di funzionalità, non è chiaro se questo dovrebbe essere divertente o serio, in entrambi i casi, è una forma MOLTO male piangere efficacemente come un bambino in tutto il mondo perché a un team di prodotti non piace / desidera la tua nuova patch di funzionalità. In ogni caso, pubblicalo, ma sii sempre magnanimo se non fosse accettato, indipendentemente da quanto illogica sembra essere la decisione. -1 - Cordiali saluti, annullerò felicemente il mio voto, se lo togli.

— ottobre

L'applicazione che voglio cambiare sta seguendo uno standard rigoroso che con le mie modifiche infrange lo standard. Penso di non essere nemmeno in grado di chiedere l'applicazione della mia patch.

— Dani,

@Slomojo OSS è pieno di persone immature, e quel genere di cose succede sempre, tutti dovrebbero essere preparati a lavorare come un mulo e poi essere respinti sulla base che a volte sono solidi e altre volte discutibili . E poi, almeno, hai sempre la possibilità di parlarne e trovare persone che sentono che forse hai ragione. Ora, biforcendo per dispetto , quello sarebbe il passo sbagliato e molto kiddish da fare.

— ZJR,

@Dani lol, dovrai davvero prendere la condivisione di una patch e parlarci a fondo. Evita di biforcarti perché ti consumerà la vita, sembra di rifattorizzare continuamente senza uno stipendio. ... comunque, controlla con la mailing list e il sistema di segnalazione bug se ce n'è uno, per vedere se qualcuno sarebbe interessato a questo tipo di estensione, forse non sei solo. Inoltre, il meglio sarebbe che avessero qualche API da estendere o un plug-in in cui inserire le modifiche. Questa è sempre l'opzione migliore in questi casi: mantenere un plugin . ... lo modificherà in.

— ZJR il

se ci sono casi di test automatizzati, eseguili prima di inviare la patch.

— oenone,

Tipicamente.

Se fosse un progetto di sistema operativo casuale, molto probabilmente risolveresti bug minori qua e là.

Alla fine invieresti una serie di modifiche, come una "patch".

Di solito otterresti i diritti di commit se le tue cose sono buone.

Sto parlando in generale e il più vago e non specifico possibile a causa della domanda

— MattyD
fonte