[20:02] * DktrKranz è riuscito ad arrivare quasi in orarii [20:07] \o [20:08] cominciamo? [20:09] DktrKranz: ora che ho cambiato router, direi di sì [20:09] cominciamo pure [20:09] DktrKranz, quando vuoi [20:09] !start [20:09] Voce non trovata: 'start' [20:10] peccato :) [20:10] giro di presentazioni [20:10] * DktrKranz è Luca Falavigna [20:10] * xdatap è Paolo Sammicheli [20:10] * warp10 è Andrea Colangelo [20:10] * BlackZ è Lorenzo De Liso [20:11] come canale d'appoggio, potremmo usare #ubuntu-it-dev [20:12] inizierei con una breve analisi di quello che è successo negli ultimi tempi nella comunità internazionale, anche per capire le vostre opinioni in merito [20:13] https://wiki.ubuntu.com/ArchiveReorganisation [20:13] * njin è Marconi Fabio [20:14] agli albori, l'archivio si divideva in main/restricted e universe/multiverse, il primo era riservato ai core developers, mentre universe era gestito dalla comunità MOTU [20:14] (principalmente) [20:14] con la diffusione di Ubuntu, e la creazione di più "varianti" (Kubuntu, Xubuntu, Mythbuntu, ecc...) è nata la necessità di gestire i pacchetti in modo un po' più strutturato [20:15] in modo che uno sviluppatore inteessato ad una "variante" (o flavour), avesse la possibilità di lavorare su un insieme di pacchetti, senza differenza tra main e universe [20:16] così sono stati creati i "set" [20:16] desktop, kde, xubuntu, myth, eccetera [20:17] ognuno con uno scopo ben preciso, e gestito da uno specifico gruppo di sviluppatori [20:17] il resto dei pacchetti non appartenenti a main o ad uno dei "set", sono stati lasciati a universe [20:18] questo ha avuto delle ripercussioni sulla comunità degli sviluppatori "generalisti", i quali non hanno più avuto modo di contribuire su un insieme di pacchetti via via più significativo [20:19] e, infatti, alcune delle attività che in passato si facevano e si coordinavano a livello di comunità (REVU day, importazione dei bugfix critici di Debian, ecc...) non vengono più svolte con regolarità [20:20] qualche giorno fa ho parlato con xdatap a proposito di questo, e sarebbe interessante farlo notare all'UDS [20:21] vi risulta? avete notato anche voi un cambiamento? [20:21] DktrKranz: decisamente [20:22] E concordo sull'opportunità di farlo notare all'UDS [20:22] per avere più peso, potremmo iniziare a stabilire una lista di cose da fare [20:23] in modo da essere da esempio per una comunità internazionale che, a mio avviso, ha perso smalto [20:23] avevo un paio di idee in mente, le illustro brevemente [20:24] 1) Collaborare con Debian per incorporare le patch introdotte in Ubuntu [20:24] partendo dai pacchetti orfani, in questo modo il carico su universe si riduce, e si "allena" gli sviluppatori a pensare più in grande [20:25] 2) gestione di alcune attività semplici (per esempio gli NBS, warp10 ha scritto una buona guida in merito) [20:25] ripartendo con queste attività, possiamo attirare nuove persone, elemento che diventa di vitale importanza [20:26] DktrKranz: molte volte non si collabora con Debian, ad esempio, ho visto core-dev non inviare patch non specifiche di Ubuntu a Debian [20:27] vero, non è possibile costringere le persone a collaborare a Debian, ma si può far notare loro i benefici [20:28] ma possiamo partire dalle patch più semplici, e iniziare a stimolare la comunità in tal senso [20:30] questo è la punta dell'iceberg, se avete altre idee che possono in qualche modo essere interessanti, anche a livello internazionale, possiamo discuterne [20:32] DktrKranz: DktrKranz: sicuramente. Un'altro problema è che ci sono molte patch da rivedere e molto lavoro in sospeso nella coda di sponsorizzazione; in genere le patch e/o le richieste per i pacchetti nei componenti universe/multiverse sono subito revisionate e caricate se vanno bene [20:32] mentre quelle per main/restricted dopo qualche tempo o forse mai revisionate; credo che il motivo di questo sia che ci sono molti MOTU e pochi core-dev; avere più core-dev volenterosi potrebbe migliorare la situazione di molto [20:32] inoltre, il lavoro in sospeso dovrebbe essere ripreso da qualcuno. Se il lavoro non è revisionato, il contributore potrebbe sentirsi scoraggiato [20:33] ops.. mi scuso per il doppio highlight :P [20:34] di core-dev c'è solo alessio (quadrispro), come comunità potremmo fare una revisione delle patch [20:34] e dare il nostro +/- 1, in modo da agevolare l'attività dello sponsor [20:34] DktrKranz: ovviamente non dovrebbe farlo solo lui; non può rivedere tutto da solo [20:34] basterebbe una patch al giorno [20:35] beh, si. Intendevo lo sponsor in generale [20:35] e da cosa nasce cosa (più lavoro, più visibilità, più possibilità di diventare core-dev, ecc...) [20:36] DktrKranz: il patch piloting è un buon programma, ma non basta [20:38] in un mondo perfetto, la patch si manda a Debian, il maintainer la applica, e si effettua il sunc [20:38] *sync [20:39] DktrKranz: dovrebbe sempre essere così, ma non sempre il maintainer in Debian vuole applicarla [20:39] DktrKranz: purtroppo, ho visto anche casi come questo: di sviluppatori Debian che non hanno alcun interesse in Ubuntu [20:39] e, che non vogliono collaborare con Ubuntu [20:40] purtroppo è vero anche questo, come ritengo sia poco utile dire "hey, questa patch viene da ubuntu!" [20:41] DktrKranz: magari non la accettano se viene da Ubuntu, ma sono sempre del parare che potrebbero accettarla successivamente se riportata da un altro sviluppatore Debian [20:41] ma i problemi "psicologici" non si possono risolvere, occorre concentrarsi su quelli tecnici, e iniziare a intervenire dove c'è possibilità di manovra [20:41] solo per la preferenza [20:41] per questo ho suggerito di cominciare con i pacchetti orfani, lì il maintainer non c'è :) [20:42] beh, ma c'è sempre upstream; bisogna provarci fino all'ultimo ad ottenere i cambiamenti nei pacchetti; che ne pensate? [20:42] (sempre se la patch non è relativa alla pacchettizzazione) [20:42] concordo [20:42] la patch dovrebbe essere il più "upstream" possibile [20:42] * segnalata [20:43] in questo modo le possibilità di una sua inclusione aumentano, e il maintainer Debian sarebbe meno riluttante ad applicarla, se il caso [20:44] già, è comunque una tendenza inoltrarla solo a Debian in entrambi i casi (sia se è relativa alla pacchettizzazione, sia se non lo è); nel caso non lo fosse, IMO dovrebbe essere riportata anche a upstream. Ma comunque se riportate al maintainer in Debian, comunque se è un buon maintainer le inoltrerebbe ad upstream [20:45] tornando al nostro piccolo, pensate possa essere utile introdurre un'attività di review periodica? [20:45] per esempio, ognuno di noi controlla (o sponsorizza, se necessario) un tot di patch al mese [20:46] sì, magari ogni giorno c'è uno di noi (o due di noi) [20:46] se il gioco non vale la candela lo si vede presto [20:46] e ci si può concentrare su altre attività [20:46] magari un giorno meno faticoso per il revisore (escludendo i week-end, chiaramente) [20:46] che ne pensate? [20:47] tipo il patch piloting [20:47] +1 [20:49] per riassumere un po', manderei un messaggio in mailing list con alcune idee che mi vengono in mente, aggiungiamo le vostre e ne discutiamo. OK come soluzione? [20:49] DktrKranz: per me va più che bene; i meeting dovrebbero comunque essere organizzati periodicamente (tipo ogni mese) [20:49] DktrKranz: +1 [20:49] tipo per discutere sull'operato e sui progressi [20:50] concordo [20:51] o almeno preparare una comunicazione "Pensieri parole e rime non baciate dal Gruppo Sviluppo" [20:52] xdatap: per quanto riguarda il Gruppo Test, potremmo essere di supporto? se sì, in quali aree? [20:52] DktrKranz, triage [20:53] DktrKranz, se volete creare un task force di triage rapido dei bug che segnaliamo nei primi 2 giorni di test delle is [20:53] ISO [20:53] DktrKranz, l'obiettivo a tendere era di creare con il tempo un gruppo a sé stante, ma se nel frattempo avete voglia [20:54] DktrKranz, sempre se vi avanza tempo, credo che trovare il lavoro nel vostro campo di azione non sia difficile [20:54] xdatap: potrebbe essere un primo passo importante. Indicativamente, il periodo più intenso è dopo la beta, giusto? [20:54] DktrKranz, non proprio [20:54] DktrKranz, noi come gruppo abbiamo adottato l'iso testing [20:54] DktrKranz, ovvero testiamo le immagini iso di ogni milestone poco prima del rilascio [20:55] DktrKranz, per evitare che escano le immagini con bug grossolani [20:55] DktrKranz, quindi è un attività che si concentra nei 2/3 giorni prima di ogni rilascio milestone [20:55] DktrKranz, dove vengono segnalate decine di bug seri in poche ore [20:56] DktrKranz, avere un triage rapido puo' aiutare il release mangare a rendersi conto dello stato dell'immagine [20:56] xdatap: hai sottomano un esempio di bug tipico? [20:56] DktrKranz, tipico no. Capita ditutto. Da kernel panic a dispute perché un angolino della finestra non è stondato [20:57] dall'elefante alla pulce, ok [20:57] DktrKranz, l'immagine scorsa ho beccato io un kernel panic, per dire. https://bugs.launchpad.net/bugs/712082 [20:57] Launchpad bug 712082 in linux "Random kernel panic during boot on a Dell Inspiron 1520" [High,Fix released] [20:57] oppure abbiamo beccato ubuntu-bug che non segnalava i bug, LOL [20:58] notevole :D [20:58] cmq, a parte tutto, credo che è importante che voi siate un gruppo forte [20:58] numeroso, attivo e dinamico [20:58] è vitale per il funzionamento di tutto il resto della comunità [20:59] quindi concentratevi sulle vostre priorità e se avete bisogno, domandate :) [20:59] can I haz bugz? [20:59] scherzi a parte, vediamo di riprendere un po' con qualche idea nuova [21:00] o vecchia, ma con nuova linfa [21:00] Da quanto tempo non abbiamo gente nuova che gira dalle nostre parti? [21:00] partiamo dalla mailing list, vediamo se abbiamo qualche idea interessante, e mettiamola in pratica [21:00] e sottoscrivo ciò che diceva BlackZ, fissate incontri mensili, pubblicate i log e bloggate su quello che fate [21:01] warp10: ogni tanto qualche voce si sente, prepariamo qualcosa di *veramente* semplice e diamola in pasto al niubbo [21:01] dovete generare rumore di fondo per attirare nuovi contributori [21:02] non so, scrivete un articolo e mandatecelo da pubblicare in newsletter, bloggate nel planet [21:03] DktrKranz: +1. C'era un tempo in cui il gruppo sviluppo era molto attivo e richiamava gente da ogni dove, e abbiamo sfornato parecchi MOTU. Dovremmo recuperare l'entusiasmo di quei tempi, e concordo sulla assoluta necessità di pubblicizzarci di più, in tutti i modi [21:03] warp10: "sì, abbiamo anche ruby, è un pacchetto!" [21:04] Ammorbidire la curva d'apprendimento con il "qualcosa di *veramente* semplice" mi sembra buono [21:04] DktrKranz: il fine giustifica i mezzi :) [21:04] di veramente semplice c'è parecchio, tiriamolo fuori [21:05] che ne so, le homepage di [omiss] ? [21:05] * warp10 si commuove ripensando ai bei temi di [21:05] tempi* [21:06] abbiamo tanti pacchetti "orfani" in Ubuntu, possiamo anche metterci di impegno per gestirli, rimuoverli, ecc [21:06] anche questo è contribuire, e il nuovo utente può essere invogliato a farlo [21:06] * warp10 annuisce [21:06] ora che abbiamo UDD, è facile fare query allo scopo [21:07] poi, se vediamo che gli sforzi non sortiscono risultati, e che questo è dovuto a fattori terzi, possiamo riportarlo all'UDS [21:10] varie ed eventuali? qualche segnalazione in particolare= [21:10] ? [21:11] DktrKranz: qual è la situazione sul forum per il nostro gruppo? C'è movimento? [21:11] qualche post ogni tanto, sono sottoscritto [21:15] se non abbiamo altro, direi di darci appuntamento in mailing list [21:15] ok [21:15] DktrKranz, pubblicate il log della riunione? [21:15] direi di si [21:16] DktrKranz: direi anche di rivedere l'intera pagina (e le relative pagine) al Gruppo Sviluppo sul wiki [21:16] s/al/del [21:17] BlackZ: già. Una parte da rimuovere è quella del repository, IMO [21:17] per me possiamo concludere qui il meeting e continuare in mailing list [21:18] ok [21:19] Saluti a tutti [21:19] grazie a tutti! [21:20] grazie a tutti per essere intervenuti, stay tuned! [21:20] * warp10 saluta tutti con la manina