Valutare una ri-organizzazione del repository

Premettendo che ho letto la documentazione :D Se ho capito correttamente, in questo repository, i branch di git sono usati un po' come cartelle con scopi molto diversi.

• master: è usato come sorgente del db/ e NON contiene il sito
• lugmap.linux.it: è usato per il sito
  • come legge il db/? → ogni tanto veniva fatto git merge master per importare il suo db/
  • IMPORTANTE: produzione mostra esattamente questo ramo.
• docs: branch con solo la documentazione ( https://gitlab.com/ItalianLinuxSociety/LugMap/-/tree/docs?ref_type=heads )

Svantaggi attuali

1. Usare vari git branch per contenere materiali completamente separati una cosa un po' esoterica, rispetto agli altri 25 repository che abbiamo, e rispetto ad altri progetti di software libero noti
2. La situazione attuale ha una curva di apprendimento relativamente alta, e i ciovani fanno un sacco di casini, e i maintainer non hanno tempo libero per spiegare ad ogni nuovo arrivato come funziona tutto quanto con questa logica del db/ separato - anche se i nuovi arrivati la leggono la documentazione, ma sono ciovani e comunque non capiscono una cippa e fanno errori lo stesso, in buona fede, o perché sono ciovani e rimbambiti :D (→ frase scritta da un ciovane! auto-ironia concessa asd)
3. Probabilmente anche per le persone esperte la situazione attuale non ottimizza il loro tempo libero. Anche loro, forse, sotto-sotto, vorrebbero semplificare la cosa. Senza stravolgere il progetto, però.

Proposta: rafforzare il ramo "lugmap.linux.it" e deprecare gli altri

Premettendo che il ramo di produzione è lugmap.linux.it, in una prima fase sarebbe possibile iniziare ad importare db/ e documentazione e tutto dagli altri rami, e deprecare questi ultimi rami affinché non si facciano più modifiche in docs eccetera. Con l'intenzione di avere tutto nel ramo lugmap.linux.it, compreso db/ aggiornato e compresa documentazione. Di fatto, rendendo lugmap.linux.it il ramo principale di lavoro. Questo non dovrebbe richiedere alcuna modifica in produzione.

Questo permetterebbe, in un secondo momento, e con calma, di rinominare il branch lugmap.linux.it in un classico master o main (archiviando il vecchio master, rinominandolo in master-legacy ad esempio) così da lavorare tutti nel master e rendere questo repository più simile a tutti gli altri 25 repository che abbiamo. Quest'ultima cosa la possiamo fare appunto, con calma, concordando la cosa con fabulus che gestisce produzione e che dovrà poi lanciare un semplice git checkout master quando si deciderà di fare questo cambio.

Vantaggi nell'adottare un singolo ramo principale:

1. simile a tutti gli altri 25 repository che già abbiamo e che lavorano su master e main, e usano altri rami solo per proposte temporanee da unire al ramo principale, e non per avere scopi diversi
2. il db/ avrebbe una singola fonte di verità (dal ramo principale) e non ci sarebbero ambiguità dai ciovani / nuovi arrivati
3. la documentazione sarebbe facilmente esplorabile ai nuovi arrivati, direttamente in locale, e direttamente da GitLab, senza sperare che capiscano che devono cambiare ramo per vederla; inoltre, la documentazione potrebbe essere di nuovo facilmente mostrata dal sito siccome sarebbe esposta sullo stesso ramo del sito

Svantaggi:

• gelma segnalava che prima era utile poter fare git log nel ramo master per vedere solo le commit sui LUG - questa cosa era utile per le notifiche a https://twitter.com/lugmap
  • → in sua sostituzione si potrebbe fare git log -- db/ dal ramo principale - dovrebbe essere equivalente
• è una migrazione, dopo tutto - e questo è uno svantaggio
• ...

Cose Stupide da poter Fare

Siamo gli ultimi arrivati quindi cerchiamo di andare piano.

In realtà tutto questo si può fare in 120 secondi con una motozzappa, ma a noi piace collaborare. asd

• capire come mai gggente ciovane (e quindi, gente stupida, boz compreso) continua a sbagliare contribuendo nei rami sbagliati - ci si chiede come salvare le nostre anime da questo continuo dire alla gente "NOOO NON CONTRIBUIRE AL RAMO lugmap.linux.it, quello contiene i dati, sì, ma sono solo uno specchio dell'anima del ramo master; cerca nella tua anima, lascia stare quel ramo, vai nell'altro" e cose del genere asd. Si può continuare a bastonare tutti, oppure si può semplificare il repo. Si decide di fare entrambe le cose. asd
• 2024-03-16 "Avete letto la documentazione?" "Boh. Dov'è?" "Nel ramo docs". Eccola asd https://gitlab.com/ItalianLinuxSociety/LugMap/-/blob/f126f858f1099ffc527b310e61b9fac5f0e9ce0a/Guida_Intergalattica_Alla_LugMap.pdf
• 2024-03-17 questa issue esiste
• 2024-04-18 sentito Roberto Guido sui rami attuali. Parafrasi: «Effettivamente si potrebbero semplificare» «Boh OK ma senti Gelma». Sentito anche Gelma. Ha chiarito lo spirito originale dei rami a voce a Boz. Boz illuminato. Su questa issue Gelma dice «Boh. l'importante è che la gente faccia contributi anche dopo».
• 2024-04-18 aperta discussione in lista LugMap - https://lists.linux.it/pipermail/lugmap/2024/002561.html
• Sul "vecchio" branch "solo dati" (che storicamente si è sempre chiamato master):
  • (primi mesi del 2024) deprecato il ramo che contiene solo i dati (che sarebbe l'attuale master)
  • (primi mesi del 2024) promosso il branch che contiene "sito+dati" come default (che sarebbe il branch lugmap.linux.it)
  • (fino a luglio 2024) guardare se la cosa è odiata o se funziona. Guardare se le modifiche semplificano nuovi contributi. Guardare se i nuovi contributori fanno gli stessi errori banali di prima (e.g. contribuire nel ramo sbagliato).
    • ✅ Fabio Lovato: ha visto il repo e ha fatto una merge request nel ramo giusto. Non c'è stato bisogno di spiegargli niente. Incredibile. Pazzesco. Straordinario \o/ abbiamo riposto i bastoni, non c'è bisogno di picchiarlo - ce47c6ea
    • ✅ Marcello Il Vichingo con Fabio Lovato: idem come sopra. !50 (merged)
    • ✅ Peter. Idem come sopra. !53 (merged)
    • ✅ onestamente anche Valerio e Dani ora possono spegnere il cervello e non commettere più l'errore di contribuire nel ramo sbagliato
  • BREAKING CHANGE eliminare il ramo "solo dati" (master). Probabilmente si può fare anche subito.
    • Ma potrebbe rompere Twitter? No: Twitter è già rotto dal 2021. asd. Quando l'aggiusteremo basterà fare git log -- db per riavere lo stesso feed.
• Sul "vecchio" branch "solo documentazione" (che storicamente si è sempre chiamato docs):
  • (luglio 2024) deprecato il contenuto del ramo che contiene solo la documentazione (ramo docs)
  • (luglio 2024) spostare la documentazione in una sotto-cartella, e poi importare quei contenuti nel ramo principale `lugmap.linux.it
  • correggere eventuali link in ingresso al ramo "solo documentazione"
  • BREAKING CHANGE eliminare il ramo che contiene solo la documentazione (il ramo docs)
• sul "vecchio" branch "solo sito" (che storicamente si è sempre chiamato lugmap.linux.it)
  • attendere qualche momento per informare tutte le persone di lavorare sul ramo main (come tutti gli altri repository di ILS)
  • correggere eventualmente la documentazione
• scegliere il nome del ramo principale (master vs main). Già che ci siamo possiamo chiamarlo main tenendo il default di GitLab.
• BREAKING CHANGE promuovere il branch del sito+dati+documentazione (lugmap.linux.it) a main e impostare main come ramo principale. Lanciare git checkout main sul server.