Su Planet KDE c’è attualmente tutto un gran discutere sui cicli di sviluppo e rilascio di KDE e dei progetti open source in genere.
Ciò sta avvenendo in risposta ad alcune dichiarazioni rese da Mark “Mr Ubuntu” Shuttlewort all’Akademy 2007 (video). La situazione sembra abbastanza ingarbugliata, tanto da richiedere molteplici interventi di sviluppatori che continuano a rincorrersi su reciproche citazioni.
In realtà basta capire di cosa stiamo parlando, e diventa tutto molto semplice, adesso vi spiego…
Mark “Colpa d’Alfredo” Shuttleworth sostiene che, da ché mondo è mondo, la convivenza porti alla spontanea sincronia del ciclo, e che questa è una naturale tendenza da incoraggiare. Cosa molto vera e riscontrabile nella realtà e che incidentalmente rappresenta un grosso vantaggio per i distributori come lui. Tutto, o quasi, è cominciato con la decisione di rilasciare GNOME 2.x a cicli perfettamente semestrali, ricorderete.
Tra gli sviluppatori KDE non sono mancate le repliche. Robert Knight afferma una grande verità quando sostiene che a volte la regolarità del ciclo può saltare, specie in caso di traumi o variazioni che portano scombussolamenti, come il passaggio a KDE 4 che ha stravolto tutti i ritmi. Sebastian Kuegler taglia la testa al toro e propone di utilizzare misure drastiche per sospendere l’avanzamento del ciclo in trunk (con metodi che poi non si sa quali conseguenze possano portare).
Aaron Seigo invece controbatte che sincronizzare i cicli ha senso solo in certi casi specifici e non deve distogliere dal fatto che secondo lui Plasma ha bisogno di mini-cicli di un paio di settimane per l’ovulazione lo sviluppo, e poi di 3-4 giorni per stabilizzare il tutto. Ovviamente un approccio come questo, più mirato al singolo progetto che alla comunità, consente di prefissarsi scadenze e tentare di rispettarle in perfetta autonomia. Insomma, chi non ha mai passato ferie in bianco per cause del genere scagli la prima pillola.
Sono perfettamente d’accordo con le esigenze di Mark Shuttleworth, anche se secondo Ogino-Knauss (padrini inconsapevoli di buona parte della nostra generazione) sembrerebbe che Aaron abbia ragione. Che abbia usato anche lui questo metodo per fare i calcoli? Non ci è dato saperlo, ma auguriamo tanta fertilità a tutti!
In base alla complessità del progetto ed all’esperienza pregressa può essere adottato un approccio agile, come profetizzato da Aron Seigo che propone mini-cicli quindicinali in KDE, oppure un approccio iterativo, come proposto in GNOME e Ubuntu. In realtà a noi utenti finali non è che interessi più di tanto, voglio dire: basta che periodicamente ci regalino tutte queste meraviglie e poi, che sia ogni quindici giorni o sei mesi, non ha alcuna importanza. Magari ci risparmiamo un po’ di unghie nel primo caso… :)
(cit)chi non ha mai passato ferie in bianco per cause del genere scagli la prima pillola
haha quanto è vero!
scusa marco ero io che ho scritto su
Il problema è che KDE è ancora un cantiere aperto dove non tutti i progetti che compongo l’intero ambiente sono sincronizzati ed allineati fra loro. Insomma, ancora non c’è uniformità di progetti in KDE 4 (e qui potrebbero rinascere le questioni, rilascio si rilascio no…ma meglio non ricominciare con sta storia) e quindi, imho, risulta impossibile pianificare un qualche tipo di scadenza regolare come avviene per Gnome.
Di sicuro oggi la forza di Gnome e del perché ultimamente ha riscontrato più successo di KDE è dovuto principalmente o per lo meno anche a questo. Cioè si è più avvicinato alle esigenze di chi sviluppa una distribuzione completa come Ubuntu, Fedora, etc…, cosa che per altro per me è sacrosanta visto che lo sviluppo di un Desktop Manager deve adottare un tipo di politica atta proprio a soddisfare le esigenze di sviluppo e rilascio di chi produce un prodotto finale e completo per l’utente, cioè per chi produce le distribuzioni.
Se KDE4 fosse stata lei stessa una distribuzione allora potevano applicare la politica che meglio credevano ma non essendolo rischierebbero fin troppo di condizionare una data distribuzione alla loro politica.
gp
"WHEN IT’S READY"
Per favore Mark e Aaron, torniamo a questo modello.
Come si fa a non capire che ogni progetto ha caratteristiche differenti?
Quoto Innovazione :)
Già è con questa politica del semestrale Ubuntu Hardy Heron si è giocato gran parte della sua stabilità. Non so voi ma a me si piantava mentre lanciavo un video con Totem oppure ho lottato con il diavolo per far prendere un ip statico al network manager cose che fin’ora non mi erano mai successe e parlo del stesso portatile che oramai uso da tre rilasci di Ubuntu.
Alla fine ho reinstallato Gutsy Gibbon è pace fatta.
in un magnifico mondo teorico la sincronia sarebbe l’ideale ma come fanno notare alcuni viviamo in una realtà frammentata di sw (de, kernel, xserver, distro e molto altro). Secondo me è impossibile mettere in sincro *tutti* i vari progetti, sono troppi e non tutti hanno le stesse risorse (manovalanza ed econoimche in primis). Senza contare gli obbiettivi di ognuno.
ad ogni modo il concetto mi piace ma lo trovo improbabile.
So che vado OT.. ma guardo i google adsense a destra.. e noto che le parole "ciclo" e "ovulazione" hanno confuso alquanto gli annunci del buon Google!! ghgh :)
Ahahahah…
Eva-test anche per KDE allora
Se Shuttleworth vuole cicli regolari per KDE, perchè non lo include in Ubuntu? e in fase di installazione è l’utente finale a scegliere quale DE installare?
Se proprio devo ‘contestare’ qualcosa a Ubuntu, è proprio questa…
A parte la diversità dei progetti, a parte la riscrittura di KDE, a parte che è come fare un nuovo stato…
Che dire, che scelgano senza troppi casini quale sia la strada migliore da prendere e si mettano il cuore in pace. KDE è un progetto bellissimo, ma sulla quarta release c’è da lavorare…non voglio però che per favorire i tempi di rilascio trascurino la scrittura di un buon codice con la conseguente possibile instabilità del sw.
Il grosso problema di KDE 4 è che al momento non si ha una release veramente stabile del DE ed è rischioso inserirlo come desktop di default. KDE avrebbe bisogno di un periodo per assestarsi e per correggere gran parte dei problemi, dopo il quale si potrebbe partire con cicli semestrali avendo in mente obiettivi ben precisi (e realizzabili). Non ammiro GNOME ne le idee di padron ubuntu, ma devo ammettere che sviluppare software avendo un ciclo di sviluppo semestrale ha reso questo DE facile da includere nelle distribuzioni che, lavorando in sincronia con il DE possono aiutarlo e migliorarlo.
@Frank
Perchè KDE 4 è un progetto sviluppato male. E’ bello, è veloce, è potente, ma inutile sotto tanti aspetti , incompleto sotto altri e incredibilmente instabile. Vorrei ricordare che la prima release di KDE 4 aveva il composite ma era molto instabile e priva di funzionalità importanti. Il problema è che quelli di KDE sembrano non avere le idee precise: è come se avessero sviluppato una macchina con il navigatore satellitare ma con i freni che ogni tanto non vanno. Io la penso così.
Sottoscrivo in pieno il pensiero di rief circa KDE.
Circa il discorso dei rilasci ciclici e stabiliti non significa necessariamente ogni sei mesi o tre o 4. Ma dare a chi sviluppa distro la possibilità di programmare con una certa certezza i propri rilasci è una cosa buona, saggia e giusta.
gp
Non è una questione di idee precise (che ci sono, e sono tante, basta leggere). È una questione di tempi e di quantità di mandopera (ed anche un problema di ricambio generazionale degli sviluppatori, che pian pianino si sta risolvendo proprio grazie all’uscita dal limbo con la versione 4.0.0, nonostante questa mossa sia stato additata come errore).
Per il resto, il post originario di Aaron non era un riflessione tra rilascio periodico sì/rilascio periodico no (i rilasci periodici sono stati un appuntamento fisso della serie 3 di KDE, sono un dato acquisito), si parlava solo di periodi adatti.
@rief
il periodo per assestarsi ce l’ha … ed è proprio questo gennaio/luglio, usato tra l’altro per andare a mettere i contenuti nell’infrastruttura. I cicli di rilascio ci sono sempre stati, ma il punto è che li si vorrebbe coordinati con quelli di gnome/ubuntu … che non ha senso. I futuri cicli saranno molto piu rapidi, perche piu rapido è il ciclo di sviluppo delle varie parti di kde … e la sincronia nel 99% dei casi rallenta e peggiora le cose, invece di accelerarle e migliorarle.
Sul fato che Kde4 sia un progetto sviluppato male, io non sono per niente daccordo, anzi, per me è l’esatto opposto … e se è incompleto e inutile sotto molti aspetti … basta ricordare che la prima release di produzione sarà la 4.1 … quindi prima di quella sarebbe davvero strano che fosse completo e utile.
Il compositing era presente nella 4.0 come primo step di integrazione (tra l’altro funzionava in maniera completamente diversa da quello che sarebbe successo con le qt4.4)
Quindi … il tuo concetto di un buon progetto .. è un progetto completo e privo di problemi a 2/3 del ciclo di sviluppo … direi che le cose non funzionano esattamente cosi eh?
Io credo che ci vogliano degli schedule precisi perchè una azienda non può dire al proprio cliente "ti dò il software quando è pronto"…ora so che ho forzato un po’ il paragone, ma se GNU/Linux vuole davvero sfondare nel mercato di massa deve anche avvicinarsi di più ad una natura commerciale.
Con schedule e obiettivi precisi e realistici.
E Ubuntu, checchè se ne dica, ha proprio questo pregio…guarda caso nessun’altra azienda produttrice di distro è mai riuscita a concludere un accordo con Dell o a penetrare tanto nel mercato Linux in così poco tempo.
Nel mercato Linux DESKTOP. Dove si rincorre l’ultimissima versione, ma poi gli utenti normali aggiornano ogni 6 mesi?
Non c’entra una mazza avere le release esattamente una settimana prima dell’uscita di una distribuzione con la stabilità (quale distribuzione, poi? Ubuntu? E Fedora, openSuSe e Mandriva che – specialmente le ultime due – danno maggiore apporto a KDE?). Anzi, meglio un po’ di periodo per vedere se il tutto funziona, se si vuole avere qualcosa di stabile.
net, in tutta il discorso, NON si è MAI messa in discussione la periodicità delle uscite. Si è solo discusso di quale sia il periodo giusto. Le uscite regolari ci sono e ci saranno.
@Golem
Se la prima release di produzione è la 4.1 allora c’è già un problema. Si rilasciano alpha e beta per fare testing, non una release spacciandola per stabile quando è ovvio che non lo è. Quando si sono resi conto che i sorgenti non erano pronti per il grande pubblico, e questo avveniva intorno al mese di dicembre, avrebbero dovuto, da sviluppatori seri, annunciare al mondo che il tempo non era bastato e rilasciare un ciclo di beta.
[OT]Riguardo all’ultimo commento…non c’era nulla di offensivo nel mio commento su KDE, ho semplicemente espresso una mia opinione e firmato il commento dicendo "io la penso così". Ora, da dove cavolo hai tirato fuori quella frase che non mi appartiene? No, le cose non funzionano esattamente così (eh?), nessuno lo ha detto e non sarò io a dirlo. Non mettere in bocca ad altri parole che non ci sono dai, è davvero un comportamento superficiale e infantile.[/OT]
Il 90% degli utenti Linux che conosco aggiorna per il semplice motivo che il supporto all’hardware più recente spesso migliora NOTEVOLMENTE a distanza di qualche mese.
Altri aggiornano perchè su Ubuntu (quando non ci sono problemi) fare un dist-upgrade è facilissimo e quindi non si vede il motivo per cui non convenga aggiornare. Poi sui server mission-critical il discorso è diverso.
E’ vero, qui non si è messa direttamente in discussione la periodicità delle uscite, perchè indirettamente si, soprattutto se molti condividono la filosofia "when it’s ready"…purtroppo il mondo reale non è il pianeta utopia di Debian (e riconosco che è un mostro sacro del mondo Linux).
E, discorso a parte e un attimo Off Topic qui, all’utente medio (ma io credo un po’ a tutti) non interessa che il WMV è un formato proprietario, il male del mondo, bla bla bla…
E fino a qualche mese/anno fa, facevo molta fatica a spiegare a coloro i quali si avvicinavano a Linux per la prima volta perchè dovevano SBATTERSI tra repositories, patch, e cose varie per vedere un benedetto filmato o ascoltare una canzone.
Grazie al cielo ci sono distro come Ubuntu, Sabayon, etc. in cui addirittura ormai è praticamente tutto automatico e, fino a qualche tempo fa, bastava installarsi il pacchetto da Synaptic da repositories che la stessa Canonical fornisce.
Cmq, tornando al discorso sul ciclo di sviluppo, francamente mini-cicli di 2 settimane mi sembrano esagerati. E’ pur vero però che al momento KDE4 è un cantiere in piena evoluzione.
grande felipe, credo che questo sia uno dei pochi siti/blog informatici in cui appare un adsense di google per i dolori mestruali…sei un genio. Credo che più che per il tema dei tuoi articoli ti seguo da anni solo per il tuo stile. No vabbè poi mi interessa anche quello di cui parli. ora sto ovulando dal piacere, a dopo, vi saluto con l’altra mano.
@rief
se il tuo rilievo a kde4.0 è l’incompletezza e l’instabilità … io non ti ho messo in bocca nulla.
a cosa dovevano rinunciare a Dicembre? … era pianificata una release .0 di pre-esercizio, dichiaratamente NON PRONTA a sostituire un DE per l’uso normale, senza possibilità di fraintendimenti … denunciandolo in ogni rivista del settore e rimbalzandolo in ogni blog … e a confermare questo c’è stato lo schedule di release mensili fino al rilascio della versione di produzione, la 4.1.
Data la natura aperta di questo SW "open-source", è stato un dovere impacchettare la versione di preesercizio, dato che era tutto comunque disponibile … per trasformare i gruppo di persone che disordinatamente ne avrebbero comunque compilato le versioni provvisorie (che avrebbero rischiato di essere un dito in c*lo) in una base di testers utili al progetto.
In una serie di contesti (le tlc per esempio) è normale che dopo il .0 non ci sia la scrittina beta e identifica semplicemente un sw che esce da una fase di mera progettazione/sviluppo a una in cui comincia a girare sulle macchine di pre-esercizio, mentre l’attività di sviluppo continua; poi, tecnicamente , in un contesto non open, il passaggio dalla beta alla .0 identifica per il fornitore il rilascio effettivo del prodotto in preesercizio e l’inizio delle attività di integrazione (alias "ti consegno l’infrastruttura definitiva in modo che tu la possa integrare, mentre io continuo a definirne le implementazioni").
ignorare tutto questo è strumentale … pur nella mia superficialità
@ net (17.)
La Microsoft rilascia il suo software quando ritiene che sia pronto, o sbaglio? E Adobe e gli altri? Hanno schedule precisi pubblici? Penso che i rilasci a cadenza prestabilita siano a cui Linux ci ha abituato, ma non si tratta della norma.
Ad ogni modo il punto è se tutti i moduli del DE debbano avere lo stesso ciclo di rilascio o meno. Cio’ non toglie che gli obiettivi possano essere pianificati in vista di una scadenza unica per tutti.
@Golem
Mi spiace ma sono stato frainteso. Non volevo dire che il mio concetto di buon progetto non è un progetto completo e privo di problemi a 2/3 del ciclo di sviluppo. Dico solo che c’è stata una cattiva progettazione iniziale, nel senso che i programmatori di KDE non hanno saputo scegliere obiettivi fattibili e non hanno saputo ordinarli per importanza.
La questione della beta non si applica solo a livello commerciale, ma tutti i software del mondo rilasciano beta per fare testing (alpha per fare testing a livello di team di sviluppo e beta per il rilascio al grande pubblico). Riguardo alla "trasformazione del gruppo di persone che disordinatamente lo avrebbero compilato", non sono daccordo per due motivi:
1) Quelli che avrebbero compilato KDE 4 prima, lo fanno ancora adesso e chissene della stabile (altrimenti i numerosi articoli di Pollycoke non sarebbero letti da nessuno).
2) Quelli che invece aspettavano la stabile di KDE 4 per provarlo si ritrovano un prodotto che non è stabile e che non assomiglia neppure a un prodotto finito. Su questi, che magari hanno provato la live di qualche rivista, che impressione credi che abbia fatto il progetto?
Non ignoro e non mi diverto a strumentalizzare le informazioni, le interpreto da utente quale sono. E per me è stata una mossa sbagliata.
Perchè ora chi non fa parte del team di sviluppo di KDE ha dei SERI problemi a usare/testare/mettere dentro una distribuzione il DE. Il problema relativo allo sviluppo del nuovo KDE è che non da certezze. Almeno per ora.
Probabilmente in futuro non sarà così, quando verrà sviluppata la vera stabile di KDE (4.1?) si avrà una base per lavorare velocemente e poter effettivamente rilasciare miglioramenti e fix molto velocemente garantendo un livello di efficienza e qualità probabilmente (ma non sicuramente) superiore a GNOME. Le kde libs e le nuove QT hanno caratteristiche di nuova generazione che pochi framework hanno.