[Python] Scelta GUI

[Giovanni Porcari]

> Il giorno 03 apr 2017, alle ore 01:01, Enrico Bianchi <enrico.bianchi a live.com> ha scritto:
> 
> On 03/30/2017 08:37 AM, Gollum1 wrote:
>> In che modo dovrebbe essere gestito un repository di sviluppo?
> Partiamo da un presupposto: queste sono mie considerazioni basate da 
> quanto ho visto in giro e da come mi regolo io nel gestire un 
> repository. Analizzando il repository BitBucket di Genropy:
> 
> Commit:
> Per come la vedo io, un commit dovrebbe essere riferito ad un solo 
> evento, ovvero mai riferirsi a due modifiche differenti. Per capirci, un 
> commit che incorpora un fix e che incorpora una modifica di sviluppo non 
> deve esistere. Inoltre, per me i commit dovrebbero essere il più 
> granulari possibile, anche riferiti al cambio di una sola linea di 
> codice (git da questo punto di vista aiuta parecchio, essendo 
> decentralizzato). Questo perché non solo è più facile capire 
> l'evoluzione del codice, ma è anche più facile eseguire operazioni di 
> rebase o di cherry-pickying. Da quello che ho visto (un paio di commit, 
> in realtà), in Genropy vengono incorporati i commit, cosa che come ho 
> detto per me è Male™
> 
> Branch[1]:
> Partiamo da un presupposto, esistono due tipi di branch: quelli di 
> sviluppo di funzionalità (i feature branch) e quelli di 
> mantenimento/hotfix del prodotto. La differenza è semplice: i primi sono 
> branch che nascono per una deviazione dello sviluppo e muoiono, mediante 
> merge o mediante cancellazione, quando questa deviazione finisce. 
> Inoltre, molti li usano per definire dei workflow differenti da quello 
> standard[2][3]. Da quello che mi è sembrato di capire, in Genropy viene 
> usato un workflow basato su di un branch di sviluppo/feature/hotfix, ma 
> mi sembra che ci siano anche dei branch che non c'entrano nulla con 
> tutto il resto. Ora, le motivazioni possono essere due: o i branch in 
> più sono di funzionalità che sono rimasti per storico o per mancata 
> cancellazione, o sono deviazioni dallo sviluppo principale per 
> customizzazioni specifiche. Nel primo caso, vedo un peccato "veniale", 
> ovvero semplicemente non è stata fatta pulizia del repository, mentre 
> nel secondo vedo un peccato più grave perché ogni customizzazione non 
> riportata nel ramo principale significa non solo che ogni fix dev'essere 
> riportato su tutti i branch, ma che c'è una gestione malsana del 
> progetto, quindi spero che il progetto non si trovi in quest'ultimo caso.
> 
> Tag:
> Qua vedo non è che ci sia molto da dire, per come l'ho intesa io i tag 
> in Genropy sono usati alla stregua di branch. Comunemente i tag in 
> qualsiasi sistema di controllo di revisione vengono usati per rilasciare 
> la nuova versione del software, tanto che basta vedere il repository di 
> un qualsiasi altro software per notare questa convenzione e che molti 
> software di supporto li gestiscono in tal senso (e.g. Github rilascia 
> automaticamente una versione del tuo software non appena compare il 
> tag). Va da sè che è qua che per me, quello che fino a sopra era 
> sopportabile (mi si perdoni il termine), diventa inaccettabile. Non vedo 
> un senso alla gestione dei tag, e quindi non è chiaro quanto e come si 
> sta evolvendo il software.
> 
> Per quanto riguarda il repository Github, invece, posto che sono 
> d'accordo con le osservazioni dell'issue aperta, quello che vedo è non 
> solo la mancanza di tag (che aiuterebbe non poco), ma uno scarso 
> utilizzo del mezzo. Per intenderci, per quanto anche io sia un 
> estimatore di BitBucket, Github permette di avere più visibilità 
> rispetto a qualsiasi altro sistema di gestione dei repository, pertanto 
> considererei veramente una migrazione del repository di sviluppo.
> 
> In definitiva, allo stato attuale quello che farei è questo:
> 
>  - Rivedrei tutti i tag utilizzando un sistema di versioning 
> esplicativo[4] rispetto all'attuale.
>  - Eliminerei tutti i branch morti, più per pulizia che altro.
>  - Ristrutturerei il repository utilizzando come tracce di esempio [2] 
> o [3], visto che ben si adattano al workflow che si sta utilizzando in 
> questo momento
> 
> Enrico
> [1] A tal proposito, consiglio sempre di seguire questo: 
> http://learngitbranching.js.org/ <http://learngitbranching.js.org/>
> [2] http://nvie.com/posts/a-successful-git-branching-model/
> [3] https://about.gitlab.com/2014/09/29/gitlab-flow/
> [4] http://semver.org/


Caro Enrico

ti ringrazio davvero tanto per questa risposta davvero completa 
e per il tempo che ci hai dedicato per analizzare i repository.
Proprio in questo momento stiamo partendo con un profondo lavoro di revisione
che va in questa direzione. Come spesso ho detto siamo un piccolo gruppo con troppo
lavoro e troppi pochi soldi per finanziarlo e quindi quando vedo che ci sono
persone come te contribuiscono non con critiche sterili ma con consigli e
offrendo contributi in base alla loro esperienza capisco come sia importante
agire per avere il tipo di esperienza di uso che le comunità open source si aspettano.

Abbiamo su Trello appena abbozzato una serie di TODO per arrivare a lavorare su Github
su un nuovo repository organizzato e tenuto come si deve. In quello sarà
ospitata la nuova versione che sarà compatibile con python3.

Se ti fa piacere e se pensi che un Genropy tenuto come si deve possa esserti
d'aiuto nel tuo lavoro sarei felice di invitarti su questa board per portare
nei tempi e modi che potrai, il tuo contributo.


Fammi sapere se è gradito :)

Con l'occasione estendo agli altri lettori della lista lo stesso invito:
se credete di poter contribuire allo sviluppo di Genropy fatemelo sapere
e sarete i benvenuti.


Ciao

G