[Python] Scelta GUI

[Enrico Bianchi]

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/