Potrebbe essere interessante sapere come si fanno le pull request.
@mandian @Giorgio lo potreste spiegare in parole povere, per me e per tutti?
Grazie 
[quote=“rugyada, post:1, topic:1112”]
lo potreste spiegare in parole povere
[/quote]Poverissime, addirittura miserevoli direi visto che ho appena fatto il primo passo.
Comunque ci provo. Bisogna avere un account github poi si entra nella pagina che contiene il file da modificare e in alto a destra si preme la matita. Se non si ha l’autorizzazione a modificare direttamente il file, come nel mio caso, si apre una copia del file in cui si fa la modifica. C’è anche un campo in cui si può aggiungere qualche dettaglio. Poi si sottopone la modifica e si apre una pagina in cui sono mostrati il testo originale e quello modificato. Si controlla e infine si “spedisce” la modifica che sarà esaminata prima di essere accettata.
1 Like
Grazie mille.
Detta così sembra facile. Vedremo… 
Prima di riassumere in breve la procedura vorrei puntualizzare che github si basa sul noto sistema di controllo di versione inizialmente sviluppato da Linus Torvalds e chiamato chiamato git. L’idea principale di git è, a differenza di altro sistemi di controllo di versione, che ciascuno sviluppatore abbia una copia completa del codice (detta fork) sulla quale lavorare nel proprio repository locale. Le modifiche effettuate sono salvate progressivamente termite un’operazione detta commit nella quale si descrive cosa si è fatto (di solito è composta da un titolo obbligatorio e da una breve descrizione opzionale ma consilgliata). Eventualmente si ha la possibilità di sviluppare modifiche in linee parallele e distinte (dette branch) sullo stesso codice. Quando il codice è pronto si può chiedere al repository di riferimento di includere le modifiche (tecnicamente di parla di merge ) nella linea principale del codice. Questa richiesta è la famosa pull request.
Una delle cose che più disorienta all’inizio è dovere fare un fork per contribuire ad un progetto perché di solito per fork si intende l’inizio di un progetto concorrente o comunque diverso dall’originale e generalmente non è vista come un’operazione amichevole. Invece secondo la git il fork è sempre il primo passo ed è del tutto neutrale sia che si voglia collaborare col progetto originale sia che se ne voglia iniziare uno nuovo.
Dopo avervi annoiato con la teoria provo a riassumere una possibile procedura per effettuare una pull request su GitHub. Per maggiori dettagli e per le immagini (non che ho il tempo adesso di includerele 
) vi rimando alla documentazione ufficiale di GitHub. La prima volta bisogna registrarsi su GitHub in modo da disporre di un repository pubblico su questa piattaforma. Riassumo di seguito i passi da compiere per una pull request (sono leggermente diversi dalla procedura ufficiale):
- Fare un
forkdel progetto originale nel propriorepository. - Selezionare il
branchsul quale si vuole operare - Modificare i file nel
forknel propriorepository(usando l’interfaccia web bisogna fare uncommitper ciascun file modificato) - Premere il pulsante
New Pull Requestsito vicino alla tendina si selezione deibranch - Compilare la parte descrittiva (titolo e descrizione)
- Inviare la richiesta.
Nel caso dei repository di OpenMandriva i branch corrispondono alle versioni rilasciate (il master corrisponde al cooker) e per ciascuno bisogna ripetere le operazione da 2 a 6. Se un bug è presente in più versioni (di quelle attualmente attive) è meglio correggerlo in ciascuna ed effettuare la relative pull request.
Questo per quanto riguarda l’interfaccia web. Le precedenti operazioni possono essere compiute il locale sul proprio pc sia facendo solo uso del terminale (ma non tutti i passaggi sono effettuabili col comando git) sia con il recente applicativo grafico sviluppato da GitHub (ce ne sono anche altri in circolazione).
Per maggiori dettagli sul funzionamento di GIT consiglio la lettura di Pro Git (è disponibile in vari formati digitali anche gratuitamente o in formato cartaceo).
Se avete ancora problemi non esitate a chiedere. Magari sarebbe utile scrivere due righe sul wiki (non penso di riuscirlo a fare nel breve/medio periodo , però se qualcuno comincia potrei aiutarlo).
@giorgio Al momento non hai effettuato ancora alcuna pull request: hai solo modificato il file .spec nel tuo repository ma in un nuovo branch. Prova invece a modificare i branch 3.0 e cooker ed inviare la pull request da questi. Forse non è la procedura migliore (in questo caso se un domani scopri un nuovo bug devi prima sincronizzare il tuo repository con l’originale o probabilmente non ti sarà possibile effettuare una nuova pull request) ma per cominciare è sicuramente più semplice.
Edit: corretti gli spazi.
1 Like
Grazie per le risposte.
Devo dire la verità la pagina di documentazione l’avevo anche aperta, ma quasi subito ho ceduto alla pigrizia che in questo periodo su argomenti di minore importanza la fa un po’ da padrona poichè devo concentrare le mie energie su altre questioni più impegnative (se non rognose 
)
Ho dimenticato di scrivere che al momento della pull request è meglio aggiornare (bump) il campo Release nel file .spec.
@rugyada All’inizio git sembra più complicato di quello che è in realtà, soprattutto per la terminologia. Dopo pochi utilizzi diventa tutto facile anche perché le operazioni da fare sono poi sempre le stesse. Però una volta che hai il tuo repository puoi costruire i pacchetti modificati/nuovi direttamente in ABF!
1 Like
[quote=“mandian, post:4, topic:1112”]
@giorgio Al momento non hai effettuato ancora alcuna pull request: hai solo modificato il file .spec nel tuo repository ma in un nuovo branch. [/quote]
Ho riprovato e mi sembra che stavolta ci sia riuscito. Anzi addirittura la pull request è chiusa , come se la modifica fosse già stata accettata. Mi sembra perfino troppo
Vedremo come va a finire.
@Giorgio comunque io il metterei entrambi in maiuscolo
E’ pur vero che sono nomi comuni, ma all’interno di una frase. In questo contesto stanno meglio in maiuscolo.
IMHO.
Non ancora.
La guida ufficiale di GitHub indica di eseguire un fork ogni volta che si esegue una modifica ed eseguire il merge nel branch opportuno (dello stesso repository) quando è pronta e testata. Ed è più o meno è quello che hai fatto. Infatti hai eseguito due nuovi fork del branch 3.0 e hai fatto la pull request al branch master(!) del tuo stesso repository. Non avendo evidenziato conflitti (i due branch originali al momento son identici) ed avendo i permessi in scrittura nel tuo repository la modifica è stata accettata ed incluse nel repository. Ma la pull request dovresti farla al repo di OpenMandriva. Puoi controllare la situazione nel grafico.
La pratica di avviare un fork ad ogni modifica e poi eseguire il merge è sicuramente virtuosa perché consente di tenere pulito il branch principale ma non obbligatoria. Nel caso di semplici modifiche a pochi file (come nel caso dei repository in questione) può essere saltata e puoi operare direttamente sui branch principali. Inoltre, una volta eseguito il merge i branch di sviluppo possono essere tranquillamente soppressi.
Per inciso in una situazione come questa avrei modificato il branch master direttamente e poi eseguito il merge in 3.0.
PS1. Aggiungo per conoscenza github non cancella mai nessun commit registrato. Anche i repository “cancellati” sono raggiungibili se si conosce l’indirizzo esatto.
PS2. @rugyada: pare che `troppe` `parole` in `preformatted text ` e `ravvicinate` in alcuni casi mangino gli spazi
pare che
troppeparoleinpreformatted texteravvicinatein alcuni casi mangino gli spazi.
Ho aggiunto dei ‘_’ dove è capitato.
Edit: correti gli spazi.
pare che troppe parole in preformatted text e ravvicinate in alcuni casi mangino gli spazi
Test.
Ho aggiunto spazi supplementari tra le parole
1 Like
Wow! Come?
Boh ho fatto così:
PS>
Ma te la puoi giocare anche usando il grassetto e il corsivo, magari lasciando il code per codice e comandi.
1 Like
Sembra che un doppio spazio prima di parole metta tutto a posto 
. Non è molto logico ma effettivamente funziona.
pare che troppe parole in preformatted text e ravvicinate in alcuni casi mangino gli spazi.
1 Like
Non ci capisco più niente.
Non so se riuscite a vedere questa pagina in cui c’è questa frase:
Pull request successfully merged and closed
You’re all set—the Giorgio-IT-patch-1-1 branch can be safely deleted.
da cui io capisco, per quel poco di inglese che so, che la pull request c’è stata eccome, ed è stata accettata addirittura 22 giorni fa.
Se non è così i messaggi di github sono da rivedere in modo che abbiano senso.
Lascio a Mandian, che mi sembra buon conoscitore di questa giungla, la verifica.
… ed il branch Giorgio-IT-patch-1-1 può essere rimosso perché non più così utile. La risposta è in un post precedente (di 22 giorni fa 
) :
https://forum3.openmandriva.org/t/le-pull-request/1112/9?u=mandian
La pull request la devi fate al repository originale, cioè OpenMandirvaAppociation. Adesso prova a fare una pull request dal branch master del tuo repository a quello di OpenMandirvaAppociation. Puoi verificare l’esito al seguente link.
@mandian Volevo chiederti un piacere, ma feel free to send me to that country se non hai tempo.
Se ti mando alcuni file aggiornati di oma welcome, lo potresti ri-impacchettare?
Forse se se lo trovano pronto ci mettono meno a portarlo nei repository OM (meno dei soliti parecchi mesi, intendo)…
Il tempo è sempre poco ma se me li mandi ci provo! 
1 Like
Grazie a @mandian, il pacchetto di oma welcome con i file aggiornati si può trovare nel suo repository personale QUI in attesa che venga approvata la famosa pull request 
L’ho testato anche in una live localizzata in italiano, e vedo che tante traduzioni mancano purtroppo.
Tuttavia rimane sempre da capire o decidere/organizzare come poter contribuire.
1 Like
Per vostra informazione, e per chiudere questo offtopic 
https://forum3.openmandriva.org/t/translation-tool/1237
1 Like