Closed 2autunni closed 8 years ago
iusondemand
commented
9 years ago Condivido tutto. Io posso seguire i testi legali, se avete bisogno guardo il codice ma in questo momento sto finendo la mia guida quindi sono piu' legal oriented :) Fate pure senza altri ok da parte mia.
Gix075
commented
9 years ago @iusondemand ok.
@2autunni sì la mia idea era quella di fare due directory principali che in fondo sarebbero come nello schema che avevo proposto: dev e dist dove in dev sviluppiamo (codice e testi) e in dist esportiamo le versioni stabili del progetto. Poi esiste anche la possibilità di fare delle release che praticamente fotografano il repository ad una data situazione. Tu dicevi di inserire una terza directory?
Gix075
commented
9 years ago @2autunni metto il link del repo che @raynor85 ha preparato sul suo account per farci vedere. A me sembra ottima, però vorrei anche il tuo parere per capire bene la tua proposta.
https://github.com/raynor85/italianPrivacyPolicy/tree/refactoring
Ovviamente la discussione è aperta a tutti.
2autunni
commented
9 years ago @raynor85 mi sembra ok: domanda la cartella node-modules non andrebbe ignorata mettendola in .gitignore? non è creata da npm -install ?
@Gix075 rispondendo al tuo commento https://github.com/FattiDiCookies/italianPrivacyPolicy/issues/73#issuecomment-117201107
Io la vedevo a rami più che a directory. Va bene avere cartelle dev e dist, ma IHMO servono i rami separati, per dare all'utente finale un prodotto stabile sempre se pesca nel ramo master.
Es Se un utente vuole compilare da sè il prodotto finito deve usare la dev di master che sarà sempre stabile non la dev del ramo di sviluppo che potrebbe non esserlo, se vuole partecipare allo sviluppo prende il ramo dev e apporta su quello le sue modifiche (forkando o meno)
Gix075
commented
9 years ago @2autunni ok non avevo afferrato. Così mi sembra un'idea più che valida. Tu che ne dici @raynor85?
raynor85
commented
9 years ago Hai ragione sulla node-modules, iniziando da un git fresco mi ero dimenticato di toglierla, e poi me la sono portata dietro nei merge. L'ho tolta. Riguardo i rami non saprei, io tendo a copiare dagli esempi che vedo in giro, come bootstrap, i quali hanno dev e dist nello stesso repo. Poi valutate il fatto che l'utente medio che scarica da git automaticamente scarica / clona da master, non si pone nemmeno il problema di un altro branch. Tuttavia quello che dici ha molto senso. Decidete voi.
Ruben
2015-06-30 16:48 GMT+02:00 Marcello Cerruti notifications@github.com:
@raynor85 https://github.com/raynor85 mi sembra ok: domanda la cartella node-modules non andrebbe ignorata mettendola in .gitignore? non è creata da npm -install ?
@Gix075 https://github.com/Gix075 rispondendo al tuo commento #73 (comment) https://github.com/FattiDiCookies/italianPrivacyPolicy/issues/73#issuecomment-117201107
Io la vedevo a rami più che a directory. Va bene avere cartelle dev e dist, ma IHMO servono i rami separati, per dare all'utente finale un prodotto stabile sempre se pesca nel ramo master.
Es Se un utente vuole compilare da sè il prodotto finito deve usare la dev di master che sarà sempre stabile non la dev del ramo di sviluppo che potrebbe non esserlo, se vuole partecipare allo sviluppo prende il ramo dev e apporta su quello le sue modifiche (forkando o meno)
— Reply to this email directly or view it on GitHub https://github.com/FattiDiCookies/italianPrivacyPolicy/issues/73#issuecomment-117214148 .
Gix075
commented
9 years ago @raynor85 @2autunni stavo anche pensando al problema delle issue da usare come strumento di assistenza. Il fatto è che un utente che verrebbe in questo repository in cerca di assistenza si troverebbe in mezzo a tutte le nostre issue in cui parliamo delle cose più disparate e non proprio inerenti a questioni di utilizzo del prodotto. Non saprei però come risolvere la cosa se non con un repository di sviluppo e uno dedicato solamente alla distribuzione, ma sarebbe un po' più noioso gestire la cosa. Voi che dite?
2autunni
commented
9 years ago @Gix075 forse le issue dovremo lasciarle agli utenti più avanti e noi spostare le discussioni "non tecniche" da qualche altra parte (anche perché le issue sono pubbliche)
@raynor85 Alla fine va bene una qualunque soluzione, basta accordarsi e seguirla :-) dal mio punto di vista l'importante è che
2autunni
commented
9 years ago @raynor85 diemnticavo: Possiamo prevedere una cartella docs nella root del progetto?
raynor85
commented
9 years ago Volevo spezzare una lancia a favore della soluzione singolo branch, che sta nel workflow. Attualmente è possibile lavorare sulla parte di sviluppo con il comando grunt, e quando si ha una versione stabile e testata, basta eseguire grunt dist, che popola la cartella di distribuzione con il numero di versione specifico. Se compariamo invece alla soluzione doppio branch, ogni volta che si vuole portare qualcosa in distribuzione bisogna allineare a mano i file dal branch di dev a quello di dist, il che è oneroso (dato che i branch sono diversi non si può usare un merge) e soprattutto può introdurre errori. Alla luce di questo (e anche del fatto che molti repo github di successo utilizzano lo stesso sistema) sono più propenso a mantenere la più semplice gestione a singolo branch.
Ruben
On Tuesday, June 30, 2015, Marcello Cerruti notifications@github.com wrote:
@raynor85 https://github.com/raynor85 diemnticavo: Possiamo prevedere una cartella docs nella root del progetto?
— Reply to this email directly or view it on GitHub https://github.com/FattiDiCookies/italianPrivacyPolicy/issues/73#issuecomment-117236594 .
2autunni
commented
9 years ago @raynor85 grazie, visto così a molto senso specie se si utilizza il metodo dei fork.
Riassumo per vedere se ho capito: all'inizio abbiamo due cartelle DIST e DEV in un unico ramo (che ci dimentichiamo esistere)
Quello che è in DIST è quello che l'utente scarica e la cartella contiene i js funzionanti, i file html generati dai markdown e la documentazione. Il codice in DEV è quello in sviluppo, non sempre allineato a DIST
Quando uno sviluppatore vuole aggiungere una feature esegue un forl e poi una pull request, avendo cura di modificare solo i file in DEV e non quelli in DIST. Quando qualcuno del team legale vuole cambiare un testo, dopo aver avuto approvazione tramite issue, lo modifica direttamente dall'editor di github in DEV (non mi sembra il caso di costringerli ad armarsi di git) Quando il codice in DEV è stabile 1 responsabile con il magico comando grunt dist crea nuova release.
È corretto? Se ci sono bachi in DIST come procediamo per correggerli se DEV è andato troppo avanti?
Gix075
commented
9 years ago @2autunni sì credo che la tua sintesi sia corretta. Per quanto riguarda i bug in dist se la dev è troppo avanti li correggiamo in dist direttamente, credo convenga (ovviamente riportando la correzione anche in dev)
Gix075
commented
9 years ago Visto che la nuova struttura sembra comunque accettata procedo con il merge della pull request di @raynor85 , quindi nuova struttura. La discussione sul numero dei rami possiamo comunque continuarla se serve. Spero che gli altri non si trovino troppo spaesati.
P.S.: ho salvato una copia del vecchio repository per i posteri.
Gix075
commented
8 years ago Chiudo per vecchiaia della issue, se serve riapriamo.
Tra le cose da fare urgentemente (vedi #71 di @Gix075 ) ci sono alcune modifiche al repository e al modo di collaborare
Per questa si è offerto @raynor85
@Gix075 propone poi di
Secondo me il problema è più articolato: adesso tutti possono effettuare commit sul master, quindi senza controllo ognuno di noi può introdurre codice non funzionante in produzione, questo al di là di chi sia a compiere il commit (gli errori possono capitare a chiunque) o di quale metodo utilizziamo: pull-request o Feature Branches Inoltre il progetto è composto da due parti: quella legale e il codice.
Gli aggiornamenti a quella legale sono prima discussi nelle issue e solo una volta approvati sono portati nel repository: sostanzialmente non c'è accesso concorrente ai file, ma è necessaria una validazione rigorosa e non automatizzabile.
Il codice invece presenta le classiche problematiche di lavorare in maniera distribuita, possiamo lavorare in maniera concorrente ed è anche possibile pensare un domani di eseguire test automatici sul codice
Proposta
Accettiamo sia il meccanismo della fork e successiva pull-request che Feature Branches (a seconda del tipo di file e della preferenza dello sviluppatore) Ognuno esegue commit sul repository solo di codice funzionante o di testi legali su cui c'è consenso nelle issue
Nel repository esistono sempre 3 rami: Master: il codice stabile a disposizione dell'utente: per ora dopo il refactoring lo congelerei fino alla prima versione accettabile Release: Ramo dove viene rivisto e testato il codice prima di spostarlo sul master come nuova versione stabile. Dev: lo spazio di lavoro, le pull request vengono accettate solo per questo ramo
Ognuno può aprire nuovi rami per aggiungere features, rispondere a issue, o fixare bug, ma sempre partendo da dev Unica eccezione i bugfix alla versione stabile che possono partire da release, se dev è troppo dissimile.
Eleggiamo una persona con la responsabilità di testare il codice sul ramo Release e autorizzare il passaggi a Master
Passiamo il codice da dev a release quando c'è sufficiente consenso fra gli sviluppatori Trattiamo le modifiche ai testi legali sempre come le modifiche al codice: aggiornare un testo porta ad aumentare il numero di versione. Questo aiuta l'utente finale a capire che qualcosa è cambiato. Che ne pensate?