GeCHI Weekly Report #2.14 - Edizione Speciale [IMPORTANTE]

[!equilibrium]

Quattordicesimo report del 2010 dei GeCHI.

Questo report è stato volutamente pubblicato con qualche giorno di ritardo perché tratta di argomenti molto importanti che coprono tematiche che non potevano essere trattate separatamente, quindi si è optato per la pubblicazione di un report che copre un lasso di tempo di 11 giorni anzichè di una settimana.

Come al solito, rinnovo l'invito a commentare il thread e ricordo che in fondo sono presenti le referenze per seguire i report tramite RSS.

===

Benvenuti al quattordicesimo GeCHI Weekly Report del 2010, il quale fornisce sommari e notizie importanti relative allo sviluppo della distribuzione Gentoo del seguente periodo: 27.03.2010 - 06.04.2010.

Gentoo sta morendo?
Una delle domande più gettonate che, da parecchi anni a questa parte, assilla la comunità Gentoo è: Gentoo è morta come distribuzione? Questo dolente tema è stato affrontato più volte anche all'interno della comunità italiana, la quale si è sempre divisa su due fronti: quelli che pensano che Gentoo non sia più sviluppata (o ha uno sviluppo eccessivamento lento) e quelli che vedono i numerosi e costanti progressi fatti dalla distribuzione nel corso degli anni. La stessa suddivisione si può riscontrare anche in tutte le altre comunità internazionali e spesso si indentifica la causa di tutti i problemi di Gentoo nell'eccessiva mancanza di dialogo tra gli sviluppatori della suddetta e i gli utenti della comunità. Questa mancanza di comunicazione in realtà non è la reale causa del problema della lentezza di sviluppo di Gentoo, ma è una conseguenza diretta di tutta una serie di problematiche interne alla Gentoo Foundation che si possono brevemente riassumere in tre punti:

• eccessiva burocrazia interna dove non necessaria e burocrazia totalmente assente laddove è richiesta maggior garanzia di qualità (retaggio in parte della vecchia gestione di D. Robbins e in parte dell'ex sviluppatore Ciaran McCreesh e dei suoi fan-boys);
• processo di reclutamento degli sviluppatori inutilmente lungo, tedioso e poco supportato dagli sviluppatori stessi;
• numero di sviluppatori insufficiente per quelle aree della Gentoo Foundation di particolare interesse per gli utenti: Gentoo Public Relations, Gentoo Documentation Project, Gentoo BugDay, Gentoo Developer Relations ecc;

Di recente queste problematiche sono state ampiamente discusse tra i vari sviluppatori Gentoo, sia sul planet (Diego Elio Pettenò ha scritto parecchi articoli a riguardo), sia sul forum internazionale e nelle mailing list, in quanto la situazione sta diventando abbastanza critica, in modo particolare non è facile reclutare nuovi sviluppatori per rimpiazzare quelli che se ne vanno, generando così rallentamenti un po' ovunque nelle varie attività di sviluppo.

Diversamente dal passato, dove le problematiche precedentemente citate furono sempre ampiamente sottovalutate e minimizzate, l'argomento è stato affrontato seriamente e lo staff di Gentoo ha deciso di intervenire con repentini cambiamenti strutturali. Questa notizia farà sicuramente felice moltissimi utenti della comunità italiana, soprattutto quelli preoccupati per il futuro sviluppo della distrubizione, ma soprattutto pone definitivamente una risposta alla fatidica domanda: Gentoo è morta?, NO! è viva e prospererà ancora per molti anni a venire.

Di seguito verranno spiegati nel dettaglio i cambiamenti strutturali che sono già in atto, mentre quelli che sono ancora in fase di pianificazione e discussione in mailing list, verranno presentati nei prossimi GWR.

[1] Nuono progetto Gentoo Wiki (05.04)
Dopo anni di continue discussioni su una possibile creazione di un Wiki ufficiale per Gentoo, si è deciso di concretizzare l'idea ed è stato finalmente creato il Gentoo Wiki Project, il cui scopo, come ben spiegato nella relativa home page, è quello di creare e mantenere un Wiki di pubblico utilizzo sia per gli sviluppatori che per gli utenti Gentoo.

Va fatto notare che lo scopo primario del Wiki non sarà solo quello di creare documentazione tecnica, ma piuttosto quello di fornire anche uno strumento di collaborazione che faciliti la comunicazione e l'iterazione tra gli utenti e gli sviluppatori; lo scopo è quindi quello di ridurre al massimo le barriere tra sviluppatori ed utenti e al contempo permettere a quest'ultimi sia di collaborare attivamente a fianco degli svilupattori che di proporre le loro idee e progetti.

Creare un Wiki per la comunità di Gentoo non è comunque un'impresa facile, non basta dire "vogliamo un Wiki" per farlo comparire magicamente, ma ci vogliono volontari che si facciano carico della manutenzione dell'infrastruttura, degli aggiornamenti software, della coordinazione dei vari team, della moderazione dei contenuti ecc, quindi chiunque tra gli utenti della comunità voglia contribuire all'impresa si faccia avanti perché si stanno reclutando volontari per i seguenti compiti:

• manutenzione e configurazione di MediaWiki;
• realizzazione di un tema grafico per MediaWiki;
• organizzazione interna del wiki;
• moderatori;

L'introduzione di un Wiki ufficiale darà sicuramente slancio e nuova linfa al progetto Gentoo nell'immediato breve e medio termine, per questo motivo l'associazione GeCHI (Gentoo CHannel Italia) invita gli utenti della comunità italiana di Gentoo e il Team di Traduzione italiana a riunirsi per preparare per tempo utile una lista delle idee, dei progetti e dei suggerimenti che avente in mente per migliorare la distribuzione e da sottoporre quando il Wiki sarà disponibile; è meglio farlo ora piuttosto che aspettare l'ultimo momento e fare le cose di fretta e MOLTO male perché non si avrà una seconda possibilità in futuro: il successo o meno del Wiki ufficiale sarà decretato anche e soprattutto dai feedback costruttivi e dalla collaborazione attiva degli utenti.

ATTENZIONE: uno dei motivi per cui si è deciso di creare un Wiki ufficiale è stato anche quello di poter rendere obsoleti tutti quei vecchi e non più mantenuti Wiki/siti NON ufficiali relativi a Gentoo sparsi per tutto il web e che generano chaos e frustazione nella comunità, quindi quando la comunità e il Team di Traduzione italiana si riuniranno sono pregati di evitare di creare l'ennesimo Wiki di coordinamento, grazie.

[2] Nuovo progetto Gentoo Heartbeat (05.04)
Una delle lamentele più pressanti degli utenti della comunità Gentoo è quella di non poter avere dati statistici precisi riguardanti l'andamento dello sviluppo della distribuzione perché non esiste un progetto che fornisca pubblicamente e con costanza tali dati (un tempo c'erano delle parziali statistiche nella defunta GWN/GMN). Per questo motivo si è deciso di colmare questa lacuna tramite il progetto Gentoo Heartbeat, ancora in fase di creazione, tramite il quale verranno forniti periodicamente i seguenti dati:

• status dello sviluppo di Gentoo - statistiche sul numero di bug chiusi giornalmente, della distribuzione dei bug per ogni herd, della distribuzione dei bug in base alle architetture, del numero dei bug in relazione al pacchetto di appartenenza ecc;
• problemi di Gentoo da supervisionare - in base ai dati statistici raccolti si decreteranno quali sono i problemi più impellenti nello sviluppo di Gentoo;
• distribuzione delle risorse - dati sui movimenti degli sviluppatori tra un herd e l'altro, numero di sviluppatori effettivamente attivi ecc;

e molti altri elementi e dettagliate statistiche saranno disponibili quando il progetto avrà raggiunto una sua maturità.

[3] Nuove politiche di reclutamento degli sviluppatori (05.04)
Come già anticipato nell'introduzione di questo GWR, uno dei problemi maggiori di Gentoo è la difficoltà nell'eseguire il ricambio generazionale degli sviluppatori a causa delle politiche di reclutamento eccessivamente burocratiche e tediose. Per questo motivo si è deciso di ridefinire tutto il metodo di reclutamento al fine di agevolare il più possibile l'ingresso di nuovi sviluppatori, ma senza perdere l'elevato standard di qualità attualmente in vigore (i Quiz per diventare sviluppatore Gentoo non sono facili da completare). L'idea al momento è ancora in fase di discussione e verte sui seguenti punti:

• rendere i Quiz di reclutamento meno demotivanti, cioè suddividerli in parti con difficoltà graduali anziché essere un unico calderone di domande di difficoltà variabile che rendono l'esperienza molto frustante ed inutilmente lunga e tediosa;
• rendere i Quiz consistenti, cioè avere differenti Quiz per ogni tematica affrontata (domande sull'infrastruttura di Gentoo, domande sull'organizzazione interna di Gentoo, domande sugli ebuild, domande sulle policy di stabilizzazione ecc) anziché trattare differenti argomenti nello stesso Quiz come avviene ora, i quali rendono tutto il processo di mentoring caotico e confuso;
• migliorare il processo di supporto da parte del mentore, cioè il mentore deve diventare molto più responsabile per tutto l'arco del processo di reclutamento del nuovo sviluppatore comunicando di più, dando maggiori feedback e disponibilità;
• migliorare l'esperienza formativa per il nuovo sviluppatore creando un canale IRC, una mailing list e un thread del forum appositi dove lo sviluppatore possa fare domande ed ottenere risposte in tempi molti brevi anziché attendere giorni o addirittura settimane come avviene ora;

[6] Ripristino del progetto Gentoo BugDay (05.04)
Chi è un utente Gentoo da molti anni sicuramente si ricorderà che un tempo esisteva il Gentoo Bugday, cioè l'incontro mensile in cui gli utenti e gli sviluppatori si incontravano su IRC per discutere e risolvere i bug principali.

Sfortunatamente tale prassi è stata abbandonata parecchio tempo fa per mancanza di sviluppatori e volontari nel portare avanti l'iniziativa, nonostante avesse conseguito ottimi risultati; per questo motivo si è deciso di riorganizzare tutto il progetto (bisogna sviluppare tutta una serie di script che permettano un più agevole inserimento e modifica dei dati presenti in bugday.gentoo.org) e di riprendere l'iniziativa: ogni primo sabato del mese, nel canale IRC #gentoo-bugday di Freenode, potete aiutare gli sviluppatori Gentoo a risolvere i bug e fare testing.

[5] Nuovo progetto Proxy-Maintainer (18.03)
Spesso molti utenti della comunità, sopratutto i neofiti, criticano aspramente la distribuzione Gentoo perché il tal pacchetto dichiarato stabile in Portage è troppo vecchio, oppure perché non è completo o mancano funzionalità critiche, ma in realtà nella maggioranza dei casi poco o nulla c'entra la distribuzione in quanto è quasi sempre un problema di ebuild che è senza un maintainer ufficiale (uno sviluppatore Gentoo che ci lavori e faccia testing ufficialmente). Questi scenari non sono affatto rari, anzi, sono molti gli ebuild che necessitano di essere aggiornati ma non hanno un maintainer ufficiale e la problematica, già precedentemente spiegata, dei tempi lunghi per il reclutamente di nuovi volontari non aiuta di certo a migliorare la situazione. Per questo motivo, parecchio tempo fa, gli sviluppatori Gentoo avevano proposto l'uso dei proxy-maintainer, cioè utenti normali che creano e sviluppano ebuild aggiornati sotto la supervisione di uno sviluppatore Gentoo, il quale ne certifica l'operato e ne inserisce gli ebuild in Portage; in questo modo si permette agli utenti della comunità di affiancarsi ai devel Gentoo nello sviluppo degli ebuild di Portage ed al contempo gli sviluppatori si ritrovano con il grosso del lavoro già fatto.

La pratica del proxy-maintainer è già stata ampiamente pubblicizzata sul planet in passato, ma non ha mai avuto un gran successo, quindi si è deciso di dare maggiore risalto ad essa creando un apposito progetto ufficiale: il Gentoo Proxy-maintainer Project (attualmente ancora in fase di creazione/testing).

Tutti gli utenti della comunità italiana di Gentoo che sono interessati a mantenere per proprio conto uno o più ebuild orfani di Portage sono fortemente incoraggiati a proporsi come proxy-maintainer; questa è la procedura da seguire per proporsi:

• aprire un bug report per il proprio pacchetto sul Bugzilla di Gentoo;
• allegare il proprio ebuild al bug report e dichiarare esplicitamente di volerne essere il proxy-maintainer;
• assegnare il bug all'herd appropriato;
• aspettare che uno sviluppatore Gentoo accetti l'offerta di proxy-maintainer;

[6] Il punto della situazione della migrazione a Git [EXTRA]
Come molti utenti Gentoo della comunità italiana sapranno già, il package manager sys-apps/portage supporta nativamente i repository in formato Git da parecchio tempo (Funtoo già usa snapshot git di Portage fin dalla versione 2.2_rc20), ma sfortunatamente non esistono ancora repository ufficiali in formato Git per Gentoo nonostante la migrazione da CVS a Git sia in atto dal lontano Aprile 2009. Questa situazione di stallo esiste perché il processo di migrazione è bloccato da molti problemi (alcuni tecnici, altri legati ai limiti di Git stesso) che devono essere ancora risolti; la buona notizia è che negli ultimi due mesi, grazie al solerte ed incessante lavoro degli sviluppatori Gentoo, la maggior parte di questi problemi sono stati risolti definitivamente (grazie anche al supporto degli sviluppatori stessi di Git), mentre permangono solo alcuni problemi di minima importanza:

• pre-upload-hook - script completati ma ancora da testare;
• commit signing - feature già presente in git v1.7 ma ancora da testare;
• thin manifest - lavori in corso;
• sparse tree - feature già presente in git v1.7 ma ancora da testare;
• testare git-cvsserver - l'utility funziona ma non è ancora stato fatto un test approfondito;

[last rites]
Il Gentoo Tree Cleaning Team segnala che i seguenti pacchetti verranno rimossi dal tree di portage entro 30 giorni:

# Vlastimil Babka (caster [at] gentoo.org) (06 Apr 2010)
# Legacy library nothing in the tree depends on. Needs 1.5 java to compile.
# Masked for removal (move to java-overlay) in 30 days. Tracker bug #292001.
dev-java/struts-legacy

# Michael Sterrett (mr_bones_ [at] gentoo.org) (05 Apr 2010)
# Needs dev-python/numeric which is going away.
# No release since 2006
games-strategy/castle-combat

# Samuli Suominen (ssuominen [at] gentoo.org) (31 Mar 2010)
# Unported to new xfce-base/exo-0.5 API and no activity
# on upstream git. Also using HAL which is deprecated.
# Masked for removal in 30 days.
xfce-extra/xfce4-volstatus-icon

# Samuli Suominen (ssuominen [at] gentoo.org) (31 Mar 2010)
# Doesn't compile with libindicator-0.3.6, and no activity
# on http://hg.foresightlinux.org/xfce/xfce4 ... or-plugin/
# Masked for removal in 30 days
xfce-extra/xfce4-indicator-plugin

# Vlastimil Babka (caster [at] gentoo.org) (31 Mar 2010)
# Masked for upstream EOL and pending security bugs that won't be thus fixed.
# Removal in 30 days. Bug #306579.
=dev-java/sun-jre-bin-1.5*
=app-emulation/emul-linux-x86-java-1.5*

chi fa uso di uno o più dei pacchetti sopra citati è fortemente incoraggiato a trovare alternative oppure a contribuire al loro mantenimento.

----

Puoi seguire i GeCHI Weekly Report tramite i seguenti canali:

• gechi.it RSS Feed;
• Twitter: GeCHI Group | GeCHI RSS Feeds;
• Identi.ca: GeCHI Group | GeCHI RSS Feeds;
• YouTube: GeCHI Group;
• FaceBook: GeCHI Group;
• Digg: GeCHI Group | GeCHI RSS Feeds;
• LinkedIn: GeCHI Group;

[riverdragon]

Applausi, il più bel report che ricordi. Un appunto sulla forma: eritaggio non mi risulta esista (immagino sia la traduzione di heritage), meglio cambiarlo con eredità.

La questione dei proxy-mantainer è proprio una bella novità, un modo per dare una mano senza accollarsi l'impegno di diventare sviluppatori.

[lordalbert]

Applausi, il più bel report che ricordi. Un appunto sulla forma: eritaggio non mi risulta esista (immagino sia la traduzione di heritage), meglio cambiarlo con eredità.

La questione dei proxy-mantainer è proprio una bella novità, un modo per dare una mano senza accollarsi l'impegno di diventare sviluppatori.

quoto in pieno! Tante iniziative che aiutano gentoo a migliorarsi sempre di più.

[!equilibrium]

Applausi, il più bel report che ricordi. Un appunto sulla forma: eritaggio non mi risulta esista (immagino sia la traduzione di heritage), meglio cambiarlo con eredità.

no era un errore di battitura per "retaggio" (che esiste come parola).
corretto grazie.

La questione dei proxy-mantainer è proprio una bella novità, un modo per dare una mano senza accollarsi l'impegno di diventare sviluppatori.

esiste da un bel po come figura, almeno un paio di anni e spero che prenda piede perché da ottimi risultati e molto velocemente.

[lucapost]

caspita, quando ho finito di leggere tutto ho controllato che la data di pubblicazione non sia il primo aprile
ottimo! sono molto felice in particolare per il wiki e per la migrazione a git!

[mrfree]

Ottime notizie

[armaoin]

Bello il GWR di questa settimana, si scoprono sempre cose interessanti (i quiz per diventare dev gentoo ).

[Apetrini]

In realtà si chiama "Ciaran McCreesh".

[Peach]

kudos per la GWN di questa settimana. davvero ottima e dettagliata.
Per quanto riguarda il discorso "ristrutturazione gentoo" direi che è fondamentale. La cosa positiva è che sembra sia stata una cosa sentita da un po' tutto, non solo dagli utenti e il modo in cui hanno reagito è prova dell'attenzione. Ora veniamo ai fatti
Ho già 3 o quattro ebuild che sono lì in bugzilla senza mantainer... sono curioso di vedere se riesco a fare quello che dici

[!equilibrium]

In realtà si chiama "Ciaran McCreesh".

grazie, corretto

[lucapost]

... sono curioso di vedere se riesco a fare quello che dici

Questo concetto può essere esteso a molti dei punti proposti dai devel. Se in tempi realistici si raggiungesse anche metà degli obiettivi posti sarebbe già un'enorme successso.

[!equilibrium]

... sono curioso di vedere se riesco a fare quello che dici

Questo concetto può essere esteso a molti dei punti proposti dai devel. Se in tempi realistici si raggiungesse anche metà degli obiettivi posti sarebbe già un'enorme successso.

il Wiki di prova è già up.

[Apetrini]

A proposito di Proxy-Maintainer. Quelli di exherbo hanno un bot in irc che si occupa di gestire le patch fornite "esternamente"; per il tempo che sono stato nel canale mi è sembrato molto utile e ha agevolato non poco i lavori.

Ovviamente bisognerebbe adattarlo un pochino(ma solo un pochino) alla struttura gentoo. Su exherbo è tutto scisso in repository, su gentoo no; comunque si potrebbero creare delle aree di competenza a cui fa capo uno sviluppatore(o piu sviluppatori). L'utente poi fa la patch, entra in irc, la posta su dpaste/pocoo/etc... e la da in pasto al bot. Quando poi arriva il responsabile di quell'area fa un check e controlla la patch e eventualmente l'approva.

Per dare un idea di massima come funziona il "hacchi" (il famoso bot) vi posto un pezzo del mio log di irc

Code: Select all

<hacchi> 4 patches in queue... slackers! (1 in ::net. 1 in ::kde. 1 in ::pioto. 1 in ::arbor)
...
<pioto> !pl ::pioto
<hacchi> 1 matching patch in queue
<hacchi>  http://paste.pocoo.org/raw/198006/ ::pioto (submitted by drantin 6 hours and 22 minutes ago) [PATCH] Bump scummvm to 1.1.0
...
<pioto> !pd ::pioto
<hacchi> Marked 1 patch done. 3 patches left in queue.

Ogni 60 minuti hacchi da un resoconto delle patch che ha in coda e mostra il tutto per aree di competenza (vedi ::net, ::pioto, ::arbor, ::kde).
Poi diciamo arriva "pioto" (uno sviluppatore che ha il suo repository che si chiama come lui in questo caso) e controlla quante e quali patch sono state postate dagli utenti per il suo repository.
Nell'esempio sopra pioto ha approvato la patch.

Vi do un altro piccolo esempio di come si aggiunge una patch

Code: Select all

<tgurr> !patchqueue http://paste.pocoo.org/raw/198081/ ::kde
<hacchi> Queued '[PATCH] Add scribus-1.3.6'. Now 3 patches in queue

Il bot è in continuo sviluppo e dovrebbe supportare sempre piu cose...

Ho fatto questo post giusto per far conoscere la cosa, magari si trova un modo per sfruttare questo tipo di organizzazione anche in gentoo...

[lordalbert]

Invece di un bot irc, non sarebbe più comodo/accessibile uno script web che fa esattamente le stesse cose? Si tratta solo di inviare l'ebuild/patch tramite script, e poi l'amministratore di turno li gestisce, magari con una propria interfaccia web. Credo sia più comodo, e non richiede accesso irc che magari non tutti hanno o vogliono avere

[!equilibrium]

Invece di un bot irc, non sarebbe più comodo/accessibile uno script web che fa esattamente le stesse cose? Si tratta solo di inviare l'ebuild/patch tramite script, e poi l'amministratore di turno li gestisce, magari con una propria interfaccia web. Credo sia più comodo, e non richiede accesso irc che magari non tutti hanno o vogliono avere

l'ebuild/patch può essere inviato tramite il bugzilla di Gentoo, non vedo il motivo di reinventare la ruota tramite IRC o tramite script web (nel medio/lungo termine chi li manterrebbe?).

[Apetrini]

Avere un bot in irc che fa ciò serve ovviamente per stimolare le persone a stare piu in irc. Un contatto cosi diretto tra gli utenti che vogliono aiutare e i loro "mentori" è molto più proficuo che nel solito bugzilla.

La presenza degli utenti nei canali dove vengono affrontate certe tematiche contribuisce anche alla loro formazione e mette nelle condizioni adeguate gli utenti a essere fruttuosi.

Affrontare tematiche complesse in irc piuttosto che sul forum risulta a mio avviso piu semplice perché c'è una interattività maggiore(tra utente-utente ma anche tra utente-mentore), nonché tempi di risposta molto corti.

Se tutti gli attuali nuovi "contributori" di #gentoo-it avessero dovuto usare mail/bugzilla/forum per fare le loro innumerevoli domande (che ricordiamolo non sono sempre domande a risposta, a volte sono richieste particolari... tipo di essere un attimino seguiti su certe fasi delicate della creazione dell'ebuild, problemi rognosi etc...) non credo che si sarebbero incamminati su quella strada o almeno avrebbero fatto molta più fatica...

[!equilibrium]

Se tutti gli attuali nuovi "contributori" di #gentoo-it avessero dovuto usare mail/bugzilla/forum per fare le loro innumerevoli domande (che ricordiamolo non sono sempre domande a risposta, a volte sono richieste particolari... tipo di essere un attimino seguiti su certe fasi delicate della creazione dell'ebuild, problemi rognosi etc...) non credo che si sarebbero incamminati su quella strada o almeno avrebbero fatto molta più fatica...

il problema dei contributori non verte sul mezzo per la segnalazione dei problemi, quanto su due altre problematiche:

1- non c'è un devel che ti caghi di striscio per il tuo ebuild, il quale rimane per anni nel Bugzilla;
2- il contributore ha inviato un ebuild ed è scritto male e/o ha parecchi problemi, ma quando il devel chiede all'utente di riscriverlo meglio (con tutti i dovuti feedback e aiuti del caso), il contributore sparisce nel nulla;

nel primo caso è un problema di numeri, per certi progetti ci sono troppo pochi sviluppatori o addirittura non ce ne sono affatto (hai voglia a lementarti che i devel sono lenti a risponderti sul Bugzilla quando non c'è nessuno disponibile non è un problema di slackerismo), mentre il secondo caso è un evidente problema di bimbominkia ed è molto meglio che se ne stia il più lontano possibile dal mondo Gentoo e che faccia perdere meno tempo possibile ai devel (che senso ha sprecare due settimane per istruire qualcuno che poi sparisce nel nulla o che si offende se gli si fanno notare degli errori nei suoi ebuild?).

In ogni caso, passare dall'attuale metodo di segnalazione dei contributi tramite email/bugzilla ad uno via IRC non risolverebbe nessuno dei due problemi sopra citati; per questo motivo è stato creato il progetto proxy-maintainer: per garantire che ci siano sempre devel disposti a prendersi carico dei contributi degli utenti.

p.s.: i contributi tramite forum non sono mai esistiti, si è sempre fatto tutto tramite email/Bugzilla, IRC si usa solo per le comunizioni.

p.p.s: esiste www-client/pybugz per chi vuole automatizzare l'invio di report al bugzilla.

[ckx3009]

Eccellenti sia l'idea della ristrutturazione che quella del wiki ufficiale (era ora).

Speriamo che il tutto si concretizzi rapidamente.

Comunque, parlando per me, non si e' mai posto il problema della "distro morta", ho sempre visto un gran numero di aggiornamenti usciti regolarmente, buon segno di distro viva ed attiva.

[djinnZ]

Posto qui la prima domanda perché non ne vale una discussione: il kernel hardened non è aggiornato da un pezzo (ed il 2.6.29 non mi pare sia il caso di usarlo) info a riguardo?

Tradurre i wiki in italiano lo potrei fare ma non davvero il tempo di mettermi a chattare (cosa che detesto tra l'altro). Attendo notizie su come fare.

Il mio primo ed ultimo contributo era ancora da verificare (ma l'avevo detto che era solo per iniziare ed andava corretto) e l'unico che si è degnato di rispondere per chiedere un upgrade era proprio un bimbominkia (che alla richiesta di chiarimenti si è defilato)... che strazio. Ho fatto prima a non averne più bisogno.

[!equilibrium]

Posto qui la prima domanda perché non ne vale una discussione: il kernel hardened non è aggiornato da un pezzo (ed il 2.6.29 non mi pare sia il caso di usarlo) info a riguardo?

se ne è parlato in ML, il progetto Hardened è senza manovalanza ma lo sviluppo c'è ugualmente; il problema della mancanza di nuovi kernel aggiornati per hardened-sources è dovuto al fatto che pax e grsec hanno regressioni con le ultime versione del kernel, le quali saranno risolte solo con la versione .33 e .34, quindi dovrai attendere ancora un po; in ogni caso lo sviluppo ufficiale è nell'overlay hardened cosamai volessi vedere/usare qualche anteprima.

Tradurre i wiki in italiano lo potrei fare ma non davvero il tempo di mettermi a chattare (cosa che detesto tra l'altro). Attendo notizie su come fare.

per queste cose ho scritto chiaramente che è meglio se il Team di traduzione italiana e gli eventuali volontari della comunità si organizzino in un apposito thread, quindi contattate Scen & company ed aprite un thread a riguardo (o usate la ml, google wave o qualsiasi altra cosa che vi piaccia) perché parlarne qui è un non-sense; detto questo, coordinarsi per le future traduzioni/contributi senza "chattare", o meglio, senza una chiacchierata informale su chi fa cosa e quando mi sembra un po come voler guidare l'automobile ma senza voler guardare la segnaletica stradale.

Il mio primo ed ultimo contributo era ancora da verificare (ma l'avevo detto che era solo per iniziare ed andava corretto) e l'unico che si è degnato di rispondere per chiedere un upgrade era proprio un bimbominkia (che alla richiesta di chiarimenti si è defilato)... che strazio. Ho fatto prima a non averne più bisogno.

dipende anche da cosa hai chiesto, se è una roba che usi solo tu o che richiede un particolare setup o hardware, difficilmente troverà spazio in portage se non date maggiori indicazioni e supporto ai devel.

[djinnZ]

Hardened è senza manovalanza

Questa non è una novità ma ho qualche preoccupazione sul fronte kernel per il ritardo.

parlarne qui è un non-sense

veramente era un commento (negativo) a come è stato riportato sul sito...

[lucapost]

ma oltre a tutte queste novità, qualcuno ha accennato la possibilità di aggiornare il motore del forom ufficiale?

[n0t]

Sbowe posso dare una mano a gestire il wiki , se c'è di mezzo il PHP/MySQL <.<