Cosa fare con il codice dalla mia richiesta pull respinta?

3

Recentemente ho inviato una richiesta di pull a un piccolo ma ben noto progetto open source. Questa richiesta di pull ha aggiunto una nuova funzionalità, oltre a test di unità (e miglioramenti ai test esistenti). Tuttavia, l'autore non accetta richieste di pull per questo progetto ... ma ciò non è stato chiarito fino a quando dopo avevo già inserito il lavoro.

Ora ho questo codice extra in giro, e sarebbe un peccato lasciarlo andare sprecato. Cosa posso fare con questo? E come posso evitare questa situazione in futuro?

    
posta JesseTG 25.10.2015 - 04:58
fonte

2 risposte

5

Su GitHub (e probabilmente anche su altri servizi), la pratica standard consiste nell'includere un file CONTRIBUTING nella directory root del progetto, con le informazioni richieste dai contributori. GitHub anche offre ai potenziali contributori un facile accesso ai contenuti di questo file quando creano problemi o richiamano richieste . Prima di intraprendere uno sforzo con l'intento di contribuire, la cosa giusta da fare sarebbe leggere il file CONTRIBUTING o contattare i proprietari del progetto. Questo ti aiuterà a determinare che cosa devi fare per fargli accettare il tuo contributo.

Se, in base a ciò che impari, il contributore accetterà richieste pull, quindi grandiose. È possibile apportare le modifiche e inviare una richiesta di pull. Finché si seguono le linee guida, dovrebbe essere accettato. Ma cosa succede quando il progetto non accetta richieste pull? Oppure, per qualche motivo la tua richiesta di pull non è accettata? Hai ancora opzioni.

In primo luogo, è possibile creare un file di patch. Git supporta questo . In qualche modo puoi distribuire il file di patch. Forse creare un problema sul progetto e allegare la patch. Se è estremamente popolare, forse il creatore riconsidererà. Potrebbe essere chiuso, tuttavia, ma se fornisci dettagli sufficienti, le persone che cercano la stessa cosa potrebbero trovare il tuo problema e la patch e riuscire ad applicarlo da soli.

Qualcosa da notare su una patch - mi raccomando di mantenerla piccola. Ad esempio, hai affermato di aver migliorato i test esistenti. In una patch, mi concentrerei sulle modifiche per implementare la tua funzione e i test nuovi o modificati per confermare la funzionalità della tua funzionalità.

Se ciò non è abbastanza buono, puoi considerare di bifrare il progetto. Puoi puntare al progetto originale nel tuo README. Non è necessario mantenerlo sincronizzato con il progetto originale, ma potrebbe essere utile. Ti permetterebbe (e forse altri, se l'autore non accetta richieste di pull) di poter inviare modifiche. Anche se non mantieni il tuo progetto aggiornato con le modifiche del progetto originale, il tuo contributo può aiutare qualcuno là fuori.

Di nuovo, se hai fatto fork, potresti aggiungere un problema come richiesta di miglioramento al progetto originale, indicando il tuo progetto. Può consentire ai proprietari di altri progetti di vedere se il tuo miglioramento è popolare e riconsiderare la sua partecipazione o aiutare le persone che trovano il progetto principale e il problema e ottenere qualcosa che li aiuti.

    
risposta data 25.03.2016 - 14:14
fonte
1

Per evitare questa situazione in futuro, chiedi ai manutentori del software se sarebbero interessati ad accettare il codice per aggiungere la tua funzione prima di impiegare il tempo a scrivere il codice.

A seconda del modo in cui viene eseguito il progetto, potrebbe volere che una richiesta di funzionalità sia documentata su un sistema di tracciamento dei problemi, forum o mailing list prima di prendere una decisione.

    
risposta data 25.03.2016 - 19:34
fonte

Leggi altre domande sui tag