Slackware ChangeLog stalling… or not?

[brainvision]

http://alien.slackbook.org/blog/slackwa ... ng-or-not/

[Bart]

E' normale, molti vedono il changelog fermo e credono che non succeda nulla. Nell'ultimo periodo (periodo? anni?) PJV ci ha abituato ad attese lunghe e snervanti per poi arrivare con una marea di novità. Che dire, ben venga l'attesa se poi il prodotto è di qualità. Alien aveva già detto in precedenti post su LinuxQuestions che presto ci sarebbero stati parecchi aggiornamenti. Non so come la pensiate voi ma a me la 13.0 non è piaciuta molto come release e ho grandi speranze e aspettative da questa prossima versione. Nel frattempo mi diverto con la current.

[d4z_c0nf]

Ahe, no PAM... e mo senti a Conraid...

[phobos3576]

A differenza di certi sciagurati, irresponsabili, Pat e il suo staff hanno la buona abitudine di testare pesantemente gli aggiornamenti della Slackware prima di rilasciarli al pubblico; in questo caso, Alien Bob sottolinea che gli aggiornamenti sono piuttosto consistenti e ciò spiega lo stallo apparente del changelog.

[Kristos]

Non sò ma secondo me tra non molto ci saranno delle novità, basta avere un pò di pazienza e ne vedremo delle belle per davvero.

[conraid]

Il "problema" è che prima c'era la -current e poi la stable. La -current era il ramo di sviluppo, dove venivano testate le cose.
Adesso invece c'è anche un ramo ad uso esclusivo del team, dove c'è un primo test, e poi passate in -current.
Siamo passati da uno sviluppo a due rami pubblici, ad uno dove ce ne sono 3, di cui uno privato
Teoricamente un po' come in debian con testing, unstable e stable, solo che li almeno è tutto pubblico.
Questa gestione sembra più una gestione di qualche distribuzione dietro alle grandi aziende, redhat, novell, etc...

[Kristos]

Il "problema" è che prima c'era la -current e poi la stable. La -current era il ramo di sviluppo, dove venivano testate le cose.
Adesso invece c'è anche un ramo ad uso esclusivo del team, dove c'è un primo test, e poi passate in -current.
Siamo passati da uno sviluppo a due rami pubblici, ad uno dove ce ne sono 3, di cui uno privato
Teoricamente un po' come in debian con testing, unstable e stable, solo che li almeno è tutto pubblico.
Questa gestione sembra più una gestione di qualche distribuzione dietro alle grandi aziende, redhat, novell, etc...

Forse questa scelta del terzo ramo è dovuta al fatto di rendere la distribuzione ancor più affidabile e stabile rispetto che a quello che avveniva sino a poco tempo fà.(questo è solo un mio pensiero ipotetico).
Da qui l'incremento di un ramo aggiuntivo per eseguire i test, infatti è come se avessero voluto prendere spunto da quelle distribuzioni che hanno un supporto aziendale alle loro spalle e che ad ogni modo hanno sempre delle risorse econominche da poter investire, ma questo potrebbe essere un modo, come dicevo per migliorare ulteriormente le release future.

[metrofox]

Io sinceramente mi ero preoccupato pure un pochettino, però sono abituato alle attese di questo genere, Pat supergiù impiega questo tempo per testare nuova roba, specialmente se parliamo di roba massiccia come KDE-4.4 ed il nuovo kernel 2.6.33(che non so se verrà incluso)

[Bart]

Il "problema" è che prima c'era la -current e poi la stable. La -current era il ramo di sviluppo, dove venivano testate le cose.
Adesso invece c'è anche un ramo ad uso esclusivo del team, dove c'è un primo test, e poi passate in -current.
Siamo passati da uno sviluppo a due rami pubblici, ad uno dove ce ne sono 3, di cui uno privato
Teoricamente un po' come in debian con testing, unstable e stable, solo che li almeno è tutto pubblico.
Questa gestione sembra più una gestione di qualche distribuzione dietro alle grandi aziende, redhat, novell, etc...

Guarda, secondo me è sempre stato così. Come fai a dire che questo prima non avveniva se il ramo è sempre stato "privato"? Vuoi che PJV e team non facciano un minimo di test prima di mettere su -current, o meglio, credi che in passato questo non accadesse? Io penso proprio di no dai....

[Vito]

Logicamente lavorare in team non è come lavorare da solo,il grosso degli aggiornamenti pesanti lo testano "internamente",raggiunto un certo grado di stabilità pubblicano in current in modo che gli utente possano testare e segnalargli bug.Almeno questa è la mia opinione!

[conraid]

Il "problema" è che prima c'era la -current e poi la stable. La -current era il ramo di sviluppo, dove venivano testate le cose.
Adesso invece c'è anche un ramo ad uso esclusivo del team, dove c'è un primo test, e poi passate in -current.
Siamo passati da uno sviluppo a due rami pubblici, ad uno dove ce ne sono 3, di cui uno privato
Teoricamente un po' come in debian con testing, unstable e stable, solo che li almeno è tutto pubblico.
Questa gestione sembra più una gestione di qualche distribuzione dietro alle grandi aziende, redhat, novell, etc...

Guarda, secondo me è sempre stato così. Come fai a dire che questo prima non avveniva se il ramo è sempre stato "privato"? Vuoi che PJV e team non facciano un minimo di test prima di mettere su -current, o meglio, credi che in passato questo non accadesse? Io penso proprio di no dai....

Prima non c'era il team, e se c'era si trattava di alcune persone che collaboravano con Pat, ora invece sembra abbastanza strutturato con bug report interno, testing, etc...
A me sembra cambiato molto il modo di lavorare di Pat
E se lo guardiamo in prospettiva è meglio adesso, altrimenti come ai tempi della malattia di Pat c'è il rischio che si fermi per cause personali

[slucky]

beh, anche per questo aspetto, dipende.....
nel senso che lavorare da solo comportava svantaggi certo, vedi problemi di salute, ma anche grandi vantaggi, come il fatto di avere un controllo totale e completo, grande libertà di azione e il tempo di rilascio era un "optional"
ecco, a me piacerebbe che si tornasse all'antico, con rilasci ogni uno-due anni e magari che lo sviluppo si svincolasse dal molosso Kde4, perchè con linux ci sono tante altre strade che si possono percorrere.....

[phobos3576]

Pat supergiù impiega questo tempo per testare nuova roba, specialmente se parliamo di roba massiccia come KDE-4.4 ed il nuovo kernel 2.6.33(che non so se verrà incluso)

KDE-4.4 purtroppo ce lo possiamo scordare.
Pat si è impuntato su PolicyKit e da quella posizione non si muove; dice che PolicyKit richiede requisiti che Slackware non è in grado di soddisfare. Si capisce subito però che Pat non sta certo parlando di requisiti tecnici (tipo dipendenze), bensì di aspetti che non gli piacciono per niente.
Il problema è che tutte le applicazioni KDE sembrano voler migrare verso KDE-4.4 accettando anche questo oggetto misterioso; potrebbe anche avere ragione Pat quando dice che PolicyKit è una "windowsizzazione" di Linux frutto della prepotenza di RedHat, ma c'è il rischio che la Slackware resti l'unica a non adeguarsi.

[Kristos]

KDE-4.4 purtroppo ce lo possiamo scordare.
Pat si è impuntato su PolicyKit e da quella posizione non si muove; dice che PolicyKit richiede requisiti che Slackware non è in grado di soddisfare. Si capisce subito però che Pat non sta certo parlando di requisiti tecnici (tipo dipendenze), bensì di aspetti che non gli piacciono per niente.
Il problema è che tutte le applicazioni KDE sembrano voler migrare verso KDE-4.4 accettando anche questo oggetto misterioso; potrebbe anche avere ragione Pat quando dice che PolicyKit è una "windowsizzazione" di Linux frutto della prepotenza di RedHat, ma c'è il rischio che la Slackware resti l'unica a non adeguarsi.

Da un certo punto di vista mi vedo pienamente daccordo con Pat sul fatto di non rendere Slackware una distribuzione M$tizzata, inoltre non sarebbe poi così male restare al di fuori degli standard a cui la gran maggioranza delle distribuzioni si devono adeguare e poi andrebbe contro la filosofia della stessa se si dovesse arrendere all'idea della standardizzazione.
Io la penso in questo modo, inoltre io ho scelto Slackware, non solo per la sua grandiosa versatilità, ma anche perchè l'ho ritenuta unica nel suo genere e diversa dal classico linux commerciale.

[Bart]

Il "problema" è che prima c'era la -current e poi la stable. La -current era il ramo di sviluppo, dove venivano testate le cose.
Adesso invece c'è anche un ramo ad uso esclusivo del team, dove c'è un primo test, e poi passate in -current.
Siamo passati da uno sviluppo a due rami pubblici, ad uno dove ce ne sono 3, di cui uno privato
Teoricamente un po' come in debian con testing, unstable e stable, solo che li almeno è tutto pubblico.
Questa gestione sembra più una gestione di qualche distribuzione dietro alle grandi aziende, redhat, novell, etc...

Guarda, secondo me è sempre stato così. Come fai a dire che questo prima non avveniva se il ramo è sempre stato "privato"? Vuoi che PJV e team non facciano un minimo di test prima di mettere su -current, o meglio, credi che in passato questo non accadesse? Io penso proprio di no dai....

Prima non c'era il team, e se c'era si trattava di alcune persone che collaboravano con Pat, ora invece sembra abbastanza strutturato con bug report interno, testing, etc...
A me sembra cambiato molto il modo di lavorare di Pat
E se lo guardiamo in prospettiva è meglio adesso, altrimenti come ai tempi della malattia di Pat c'è il rischio che si fermi per cause personali

Non lo so, questa sensazione l'ho anche io ma rimane appunto una sensazione, senza dati di fatto. Nessun annuncio pubblico, unica cosa che ricordo è solo l'appoggio di un team brasiliano che ha "sostituito" Pat per i security advisories durante il brutto periodo della sua malattia. Poi non si è saputo più nulla. Nei changelog cita la parola "team" ma non so niente di più.