Come partecipare al ciclo di sviluppo di Ubuntu - 2ª Parte: Triage e Packaging.
WARNING: This presentation uses the UBUNTU FONT: http://font.ubuntu.com
Partecipare al ciclo di sviluppo di Ubuntu - 1ª PartePaolo Sammicheli
Come partecipare al ciclo di sviluppo di Ubuntu - 1ª Parte: Testing e Bug Report. WARNING: This presentation uses the UBUNTU FONT: http://font.ubuntu.com
Presentazione di Ubuntu, della comunità internazionale di Ubuntu e della comunità italiana di Ubuntu: chi le compone, come funzionano, come sono organizzate, come parteciparvi.
Partecipare al ciclo di sviluppo di Ubuntu - 1ª PartePaolo Sammicheli
Come partecipare al ciclo di sviluppo di Ubuntu - 1ª Parte: Testing e Bug Report. WARNING: This presentation uses the UBUNTU FONT: http://font.ubuntu.com
Presentazione di Ubuntu, della comunità internazionale di Ubuntu e della comunità italiana di Ubuntu: chi le compone, come funzionano, come sono organizzate, come parteciparvi.
Retrospettiva Ubuntera 2004-2010: Agilità come vantaggio competitivo? Breve panoramica sulle metodologie Agili e analisi degli elementi di differenziazione di Ubuntu.
Presentazione fatta a Novegro il 31 Marzo 2012 da Dario Cavedon, della Comunità Italiana ubuntu-it su come è organizzata la comunità e come si può contribuire a Ubuntu
Dimitri favre #noprojects - Modern software development focuses on Teams and...Dimitri Favre
Lo sviluppo del software moderno e agile può fare a meno dei progetti? Quali sono le disfunzioni del modo di pensare orientato ai progetti?
Queste le slide del mio intervento ad Agile Venture Milano 2019
L'innovazione manageriale nello sviluppo dei servizi e dei prodottiClaudio Saurin
Oggi ci troviamo a fronteggiare la velocità e l'imprevedibilità del cambiamento, spesso interagendo in modo non lineare con molti elementi fra loro diversi: questa è la definizione di complessità delle organizzazioni.
In questo contesto, innovare il processo di sviluppo di servizi e prodotti è strategico; si tratta di una innovazione manageriale che è prima di tutto una innovazione culturale.
Per fare questo occorrono nuovi stili di leadership e nuove modalità di gestione dei progetti.
Cercheremo di raccontare il passaggio che sta avvenendo nello stile manageriale in diversi contesti, lontano da noi, in modo eclatante (Toyota, Google, Apple) o vicino a noi, in modo silenzioso (la bella azienda della profonda provincia veneta, Breton).
Il manager deve cambiare, guidando il suo team in modo condiviso e divenendone parte integrante, in un panorama che, pur complesso e frammentato, offre strumenti per essere affrontarlo con più serenità.
Le metodologie Lean di derivazione Toyota e le metodologie Agili elaborate per sostenere lo sviluppo turbolento del software, gli strumenti della community 2.0 ed il classico Gantt di progetto, diventano gli ingredienti che, miscelati in funzione del tipo di organizzazione e del progetto, consentono di gestire con efficacia ed efficienza la complessità dei progetti di oggi.
E' riportato anche un esempio di una applicazione di Hybrid Project Management per la gestione dei cantieri edili, sviluppata in collaborazione con l'architetto Daniela Rinaldi di Verona.
Wpc2019 - Distruggere DevOps, la storia di un vero teamAlessandro Alpi
Consigli per evitare la distruzione della migrazione culturale verso DevOps. Vedremo un team con "attori" importanti provare a migrare verso buone pratiche e capiremo quanto è difficile arrivare, ma semplice distruggere tutto.
Presentazione per Codemotion Milan 2014
La piattaforma Ubuntu, quali sono le tecnologie utilizzate da Ubuntu per la nuova piattaforma.
Da dove partire a sviluppare nuove app per Ubuntu Touch e Desktop con l'Ubuntu SDK. Piccola introduzione al linguaggio QML.
Come contribuire alle Core Apps e come mettersi in contatto con la community di Ubuntu-it
... ovvero MIR, un display server per domarli tutti (Wayland permettendo)
In chiusura del keynote dell’Ubuntu Developer Summit del 2011, il benevolente dittatore di Ubuntu, Mark Shuttleworth, dichiarava a chiare lettere di voler portare Ubuntu su un range di dispositivi molto diversi dal canonico computer. Tre anni dopo i diversi progetti paralleli portati avanti per concretizzare questo intento stanno per raggiungere il grande pubblico. Primo fra tutti c’è MIR, il display server che è stato espressamente pensato per sostituire e migliorare un mostro sacro come X Window System. Quali nuove prospettive offre a utenti e sviluppatori? Quale il rapporto con altre soluzioni software simili? Scopriamolo insieme, su Ubuntu 14.10.
Set up and management of an integrated information system on Linux.Andrea Marchetti
ITA: Configurazione e gestione, su piattaforma Linux, di un sistema informativo integrato.
The goal is to configure a Linux Server to host a Web Server capable to run Java based applications in a Windows 2000 domain (using Samba protocols).
The main purpose of this server in the company is to offer an environment to a multi platform test of Java Web Based applications developed by Gruppo Servizi and for file sharing.
Come realizzare una distribuzione Linux per innovare e trovare lavoroAlessio Fattorini
Linux, ad oggi, è un sistema molto diffuso e utilizzato, ci sono numerose distribuzioni che spaziano tra i più svariati ambiti applicativi, da distribuzioni ad uso desktop come Ubuntu a distribuzioni server-oriented come CentOS. Nonostante siano accomunate dallo stesso cuore, Linux, differiscono sotto diversi aspetti e diversi metodi di realizzazione. Sul fronte desktop, nonostante siano numerose le distribuzioni non è il punto di riferimento per end-user, mentre lato server è il leader indiscusso da una decina d'anni a questa parte, piazzandosi benissimo sia a livello medio-basso (per PMI) sia nella fascia high-end.
La sfida di questo seminario è far luce sulla definizione, sulla realizzazione e sul mantenimento e sviluppo di una distribuzione Linux orientata all’innovazione, apprendendo i concetti basilari che forniscono know how facilmente spendibile nel mondo del lavoro.
Con la filosofia Open Source, il mondo Linux è cresciuto velocemente, regalando nuove funzionalità, nuovi prodotti e nuove conoscenze. Il seminario affronterà il concetto di Open Source, mostrando quanto sia utile e produttivo creare software che sia condivisibile, riusabile e soprattutto funzionale.
Il pensiero Open Source non si limita solamente al mondo del software, ma è un modo alternativo di pensare e di creare, la condivisione è crescita.
Retrospettiva Ubuntera 2004-2010: Agilità come vantaggio competitivo? Breve panoramica sulle metodologie Agili e analisi degli elementi di differenziazione di Ubuntu.
Presentazione fatta a Novegro il 31 Marzo 2012 da Dario Cavedon, della Comunità Italiana ubuntu-it su come è organizzata la comunità e come si può contribuire a Ubuntu
Dimitri favre #noprojects - Modern software development focuses on Teams and...Dimitri Favre
Lo sviluppo del software moderno e agile può fare a meno dei progetti? Quali sono le disfunzioni del modo di pensare orientato ai progetti?
Queste le slide del mio intervento ad Agile Venture Milano 2019
L'innovazione manageriale nello sviluppo dei servizi e dei prodottiClaudio Saurin
Oggi ci troviamo a fronteggiare la velocità e l'imprevedibilità del cambiamento, spesso interagendo in modo non lineare con molti elementi fra loro diversi: questa è la definizione di complessità delle organizzazioni.
In questo contesto, innovare il processo di sviluppo di servizi e prodotti è strategico; si tratta di una innovazione manageriale che è prima di tutto una innovazione culturale.
Per fare questo occorrono nuovi stili di leadership e nuove modalità di gestione dei progetti.
Cercheremo di raccontare il passaggio che sta avvenendo nello stile manageriale in diversi contesti, lontano da noi, in modo eclatante (Toyota, Google, Apple) o vicino a noi, in modo silenzioso (la bella azienda della profonda provincia veneta, Breton).
Il manager deve cambiare, guidando il suo team in modo condiviso e divenendone parte integrante, in un panorama che, pur complesso e frammentato, offre strumenti per essere affrontarlo con più serenità.
Le metodologie Lean di derivazione Toyota e le metodologie Agili elaborate per sostenere lo sviluppo turbolento del software, gli strumenti della community 2.0 ed il classico Gantt di progetto, diventano gli ingredienti che, miscelati in funzione del tipo di organizzazione e del progetto, consentono di gestire con efficacia ed efficienza la complessità dei progetti di oggi.
E' riportato anche un esempio di una applicazione di Hybrid Project Management per la gestione dei cantieri edili, sviluppata in collaborazione con l'architetto Daniela Rinaldi di Verona.
Wpc2019 - Distruggere DevOps, la storia di un vero teamAlessandro Alpi
Consigli per evitare la distruzione della migrazione culturale verso DevOps. Vedremo un team con "attori" importanti provare a migrare verso buone pratiche e capiremo quanto è difficile arrivare, ma semplice distruggere tutto.
Presentazione per Codemotion Milan 2014
La piattaforma Ubuntu, quali sono le tecnologie utilizzate da Ubuntu per la nuova piattaforma.
Da dove partire a sviluppare nuove app per Ubuntu Touch e Desktop con l'Ubuntu SDK. Piccola introduzione al linguaggio QML.
Come contribuire alle Core Apps e come mettersi in contatto con la community di Ubuntu-it
... ovvero MIR, un display server per domarli tutti (Wayland permettendo)
In chiusura del keynote dell’Ubuntu Developer Summit del 2011, il benevolente dittatore di Ubuntu, Mark Shuttleworth, dichiarava a chiare lettere di voler portare Ubuntu su un range di dispositivi molto diversi dal canonico computer. Tre anni dopo i diversi progetti paralleli portati avanti per concretizzare questo intento stanno per raggiungere il grande pubblico. Primo fra tutti c’è MIR, il display server che è stato espressamente pensato per sostituire e migliorare un mostro sacro come X Window System. Quali nuove prospettive offre a utenti e sviluppatori? Quale il rapporto con altre soluzioni software simili? Scopriamolo insieme, su Ubuntu 14.10.
Set up and management of an integrated information system on Linux.Andrea Marchetti
ITA: Configurazione e gestione, su piattaforma Linux, di un sistema informativo integrato.
The goal is to configure a Linux Server to host a Web Server capable to run Java based applications in a Windows 2000 domain (using Samba protocols).
The main purpose of this server in the company is to offer an environment to a multi platform test of Java Web Based applications developed by Gruppo Servizi and for file sharing.
Come realizzare una distribuzione Linux per innovare e trovare lavoroAlessio Fattorini
Linux, ad oggi, è un sistema molto diffuso e utilizzato, ci sono numerose distribuzioni che spaziano tra i più svariati ambiti applicativi, da distribuzioni ad uso desktop come Ubuntu a distribuzioni server-oriented come CentOS. Nonostante siano accomunate dallo stesso cuore, Linux, differiscono sotto diversi aspetti e diversi metodi di realizzazione. Sul fronte desktop, nonostante siano numerose le distribuzioni non è il punto di riferimento per end-user, mentre lato server è il leader indiscusso da una decina d'anni a questa parte, piazzandosi benissimo sia a livello medio-basso (per PMI) sia nella fascia high-end.
La sfida di questo seminario è far luce sulla definizione, sulla realizzazione e sul mantenimento e sviluppo di una distribuzione Linux orientata all’innovazione, apprendendo i concetti basilari che forniscono know how facilmente spendibile nel mondo del lavoro.
Con la filosofia Open Source, il mondo Linux è cresciuto velocemente, regalando nuove funzionalità, nuovi prodotti e nuove conoscenze. Il seminario affronterà il concetto di Open Source, mostrando quanto sia utile e produttivo creare software che sia condivisibile, riusabile e soprattutto funzionale.
Il pensiero Open Source non si limita solamente al mondo del software, ma è un modo alternativo di pensare e di creare, la condivisione è crescita.
Presentata alla quinta Girl Geek Dinner Milano, il 24 ottobre da Sara Rosso e Bruna Gardella. Un introduzione all'Open Source, il mondo della donna e l'Open Source, la Girl Geek e l'Open Source, e tanti modi di essere più coinvolto nel mondo Open Source.
Presentata alla quinta Girl Geek Dinner Milano, il 24 ottobre 2008 da Sara Rosso con la contribuzione di Bruna Gardella. Un introduzione all’Open Source, il mondo della donna e l’Open Source, la Girl Geek e l’Open Source, e tanti modi di essere più coinvolto nel mondo Open Source.
Collaborazione, Decisionalità e Gestione della Complessità nel Tempo: cosa ...Commit University
Vuoi migliorare la gestione dei progetti a lungo termine con team multidisciplinari e prendere decisioni rischiose in modo sicuro e ponderato? Non perderti il nostro workshop gratuito!
Antonio Dell’Ava, Frontend Developer di eDreams Odigeo, condividerà strategie per aiutarti a ottimizzare la collaborazione nel tuo team, scegliere gli strumenti giusti per ogni situazione e garantire l’evoluzione del progetto nel tempo
Intervista virtuale realizzata da Agnese Garavaglia Richard Matthew Stallman. L’ intervista è stata realizzata nell’ ambito del corso di Didattica della matematica svolto dal Prof. Giovanni Lariccia presso l’ Università Cattolica del Sacro Cuore di Milano nell’ anno accademico 2009 - 2010
Breve introduzione al Software Libero, orientato ad un pubblico di ragazzi e studenti, per dar loro una prospettiva più ampia sul mondo dell'Informatica e qualche indizio su come entrare a far parte delle Community legate al Free Libre and Open Source Software.
Similar to Partecipare al ciclo di sviluppo di Ubuntu - 2ª Parte (20)
How much business agility can an organization achieve? Is this related to the nature of the organization? To its business model, size, culture, geographical distribution, leadership? Yes, certainly all these elements play a fundamental role in how and in how much agility we can expect to have.
You might be surprised to know, though, that there are different ways in which those elements can contribute, which means that business agility is achievable in quite different types of organizations, sometimes unexpectedly.
In this session, we are going to relate part of the journey that the speakers, in their function of business agility coaches, are traveling with one of their clients, Pietro Fiorentini Spa, an Oil&Gas multinational company.
This company is exceptionally well-versed in Lean methods, which they have brought outside of just production and into different functions of the organization, and this has provided them with a great deal of efficiency in what they do.
However, they realize that efficiency (“doing the thing right”) without effectiveness (“doing the right thing”) is worthless or even harmful.
So their quest for business agility is a challenge in preserving all that makes them so efficient and improving, through news processes and ways of collaborating, their effectiveness.
We are going to discuss some of the changes that are being implemented in terms of leadership, self-organization, and team autonomy in several functions, including concrete examples coming form the designing and building of one of their production lines.
We intend to illustrate how business agility goes beyond production (certainly way beyond software production) and can coexist — and be synergetic — with some well-established management approaches.
Originally presented the 12 September 2020 at Agile Business Day, Andrea Provaglio, Paolo Sammicheli, and Andrea Aganetti.
Numerose stimate società internazionali di consulenza hanno iniziato ad offrire servizi di trasformazione agile, accattivanti e convincenti. Ottimo, vuol dire che le aziende del futuro saranno tutte agili? Purtroppo no. Scopriamo insieme i tratti caratteristici di queste proposte, i numerosi limiti ed i rischi collegati.
In the last two years, numerous Managers approached me, asking an opinion about propositions they got from very known consultancy firms regarding "Agile Transformation Initiatives." Noticing common traits, I came up with the name of "Cosmetic Agile." What are the pros and cons of this approach? When could it be useful? Is it worth the money? How to recognize "Cosmetic Agile" and how would it be different from a real Agile approach?
Engineering practices in Scrum for Hardware - Sisma Spa Case StudyPaolo Sammicheli
How to iterate quickly a physical complex product, composed by Software, Electronic, Mechanics, and Plastics, using an Agile framework like Scrum?
How to speed up the feedback loop, reducing risks and adding creativity and innovation at the same time? How to start transforming a company into an Agile Organization? In this talk, I'll try to answer to the typical hot questions I deal with doing Agile Coaching in the manufacturing industry and I'll show the journey of an Italian company, Sisma Spa, with their CEO Vittorio Gaudino.
My presentation at Scrum Day 2019, Stuttgart Germany.
Abstract: "In this talk, I'll show you how to Scrum the development of a Hardware product, composed by Software, Hardware, Mechanical parts and Plastics using the engineering practices known as eXtreme Manufacturing, invented by Joe Justice in the Wikispeed project. Additionally, there is an example on how to use the Scrum@Scale scaling patterns to scale up the development to multiple Scrum Teams and many external suppliers."
https://www.scrum-day.de/vortraege/details/vortrag-2019-scrumscale-with-hardware.html#details
How to use Scrum to create complex and innovative products?
In this talk, you’ll see how to use Scrum to develop complex product composed by Software, Electronics, Mechanics, Engines, and Plastics. You'll hear the stories of the pioneer of Scrum for Hardware, from Wikispeed to the first Scrum for Hardware Gathering and the Agile Product Charter. The discussion will include how to produce physical products using the same Scrum methods that Agile software teams have benefited from for years, how to spark product and hardware innovation through iterative sprint cadence and the secrets of companies that have made the jump from Agile prototyping to true Agile manufacturing.
Agile Lean Europe 2018 - Zurich, 22-24 August 2018. What is an Agile Organization and how transform your company in an Agile Organization with Scrum@Scale.
Industrial Agility: Come Rispondere alla Quarta Rivoluzione IndustrialePaolo Sammicheli
Intervento al Meetup Agile Venezia sulla metodologie Scrum nel contesto dell'Industria Tradizionale e la Quarta Rivoluzione Industriale. Casi reali: Wikispeed, Saab Gripen. Video: https://www.youtube.com/watch?v=3Sf-g6j6mzA
Agile London: Industrial Agility, How to respond to the 4th Industrial Revolu...Paolo Sammicheli
Agile London at Photobox/Moonpig, 16 February 2017.
Talk about Wikispeed, Scrum for Hardware and the Fourth Industrial Revolution. What means Industrial Agility and from where to start?
Industrial Agility, Come rispondere alla quarta Rivoluzione IndustrialePaolo Sammicheli
Presentazione al MINI Italian Agile Day di Vimercate, sede Nokia.
#MiniIAD #Scrum4HW Thanks to the Italian Agile Movement.
http://www.agileday.it/mini/2017/vimercate/
Presented during the Debian/Ubuntu Community Conference 23-24 May 2015.
«We'll discuss some Leadership Models (Hero, Servant and Host) and how these models can be useful leading an open source volunteering based project.»
I will show the tools and the infrastructure that makes easy creating own python project in Ubuntu and distributing it to millions of users. It will be shown several tools: Launchpad, Quickly and and the Ubuntu’s PPA (personal package archiving).
21. CODICE DI CONDOTTA Siate premurosi. Il vostro lavoro sarà usato da altre persone, e voi a vostra volta dipenderete dal lavoro degli altri. Ogni decisione presa coinvolgerà utenti e colleghi, e ci aspettiamo che prendiate in considerazione le conseguenze di ogni decisione. Ad esempio, quando siamo in uno stato di "freeze", non fate drammatici upload di nuove versioni di software per sistemi critici, in quanto altre persone sono in fase di test dei sistemi "congelati" e non sono in grado di assorbire grandi variazioni. Siate rispettosi. La comunità Ubuntu ed i suoi membri si rivolgono l'un l'altro con grande rispetto. Ciascuno può realizzare un valido contributo ad Ubuntu. Non possiamo sempre essere d'accordo, ma il disaccordo non è una scusa per un comportamento e per modi scorretti. Potremmo tutti vivere qualche frustrazione talvolta, ma non potremmo mai permettere che tale frustrazione si trasformi in un attacco personale. E' importante ricordare che una comunità dove le persone si sentono a disagio non è una comunità produttiva. Ci aspettiamo che i membri della comunità Ubuntu siano rispettosi sia quando hanno a che fare con altri collaboratori, sia con persone al di fuori del progetto Ubuntu, sia con gli utenti. Siate collaborativi. Ubuntu e Free Software collaborano e lavorano insieme. La collaborazione riduce la ridondanza del lavoro compiuto del mondo Free Software e migliora la qualità del software prodotto. Dovreste tendere a collaborare con altri maintainers Ubuntu, così come con la comunità a monte che è interessata al vostro lavoro. Il vostro lavoro dovrà essere eseguito con trasparenza e le patch per Ubuntu devono essere consegnate alla comunità quando si rendono disponibili, non al rilascio dell'edizione. Se volete lavorare a nuovo codice per progetti esistenti, almeno mantenete informati delle vostre idee e progressi i responsabili di quei progetti. Potrebbe non essere possibile ottenere il consenso circa la corretta implementazione di un'idea, così non sentitevi obbligati ad ottenere un accordo prima di iniziare, ma almeno mantenete informato del vostro lavoro il mondo esterno, e pubblicatelo in modo tale da consentire altri di svolgere prove, discussioni e contribuire ai vostri sforzi. Quando non siete d'accordo, consultate gli altri. Disaccordi, sia politici che tecnici, avvengono ogni giorno e la comunità Ubuntu non ne è esente. L'obiettivo importante non è evitare i disaccordi o le diverse vedute, ma di risolverli costruttivamente. Dovreste sempre tornare alla comunità ed ai suoi processi per cercare consigli e risolvere disaccordi. Ci sono sia il Technical Board che il Community Council che vi aiuteranno a decidere il giusto corso di Ubuntu. Ci sono inoltre diversi Project Teams e Team Leaders, che vi aiuteranno a capire quale direzione potrebbe essere la più accettabile. Se alla fine volete comunque prendere una strada diversa, vi invitiamo a fornire una diversa distribuzione o un set di pacchetti alternativo usando la struttura dell'Ubuntu Package Management, affinchè la comunità possa comunque provare i vostri cambiamenti e le vostre idee, e contribuire alla discussione. Quando non siete sicuri, chiedete. Nessuno sa tutto, e nessuno si aspetta che l'altro sia perfetto nella comunità Ubuntu. Rivolgere domande evita molti problemi lungo il percorso, e quindi le domande sono incoraggiate. Coloro che devono rispondere, dovranno essere reattivi e di grande aiuto. Comunque, nel porre una domanda, occorre avere cura nel rivolgersi al forum appropriato. Domande fuori-tema, come ad esempio una richiesta di supporto in una mailing list di sviluppo distoglie da una discussione produttiva. Lasciate con considerazione. Gli sviluppatori di ogni progetto vanno e vengono, e per Ubuntu non è diverso. Quando lasciate un progetto, del tutto o in parte, fatelo cercando di minimizzare le ripercussioni sul progetto stesso. Ciò significa che dovreste avvisare prima di lasciare e intraprendere le opportune azioni per assicurare che gli altri possano riprendere dal punto da voi lasciato.
22. CODICE DI CONDOTTA Siate premurosi. Il vostro lavoro sarà usato da altre persone, e voi a vostra volta dipenderete dal lavoro degli altri. Ogni decisione presa coinvolgerà utenti e colleghi, e ci aspettiamo che prendiate in considerazione le conseguenze di ogni decisione. Ad esempio, quando siamo in uno stato di "freeze", non fate drammatici upload di nuove versioni di software per sistemi critici, in quanto altre persone sono in fase di test dei sistemi "congelati" e non sono in grado di assorbire grandi variazioni. Siate rispettosi. La comunità Ubuntu ed i suoi membri si rivolgono l'un l'altro con grande rispetto. Ciascuno può realizzare un valido contributo ad Ubuntu. Non possiamo sempre essere d'accordo, ma il disaccordo non è una scusa per un comportamento e per modi scorretti. Potremmo tutti vivere qualche frustrazione talvolta, ma non potremmo mai permettere che tale frustrazione si trasformi in un attacco personale. E' importante ricordare che una comunità dove le persone si sentono a disagio non è una comunità produttiva. Ci aspettiamo che i membri della comunità Ubuntu siano rispettosi sia quando hanno a che fare con altri collaboratori, sia con persone al di fuori del progetto Ubuntu, sia con gli utenti. Siate collaborativi. Ubuntu e Free Software collaborano e lavorano insieme. La collaborazione riduce la ridondanza del lavoro compiuto del mondo Free Software e migliora la qualità del software prodotto. Dovreste tendere a collaborare con altri maintainers Ubuntu, così come con la comunità a monte che è interessata al vostro lavoro. Il vostro lavoro dovrà essere eseguito con trasparenza e le patch per Ubuntu devono essere consegnate alla comunità quando si rendono disponibili, non al rilascio dell'edizione. Se volete lavorare a nuovo codice per progetti esistenti, almeno mantenete informati delle vostre idee e progressi i responsabili di quei progetti. Potrebbe non essere possibile ottenere il consenso circa la corretta implementazione di un'idea, così non sentitevi obbligati ad ottenere un accordo prima di iniziare, ma almeno mantenete informato del vostro lavoro il mondo esterno, e pubblicatelo in modo tale da consentire altri di svolgere prove, discussioni e contribuire ai vostri sforzi. Quando non siete d'accordo, consultate gli altri. Disaccordi, sia politici che tecnici, avvengono ogni giorno e la comunità Ubuntu non ne è esente. L'obiettivo importante non è evitare i disaccordi o le diverse vedute, ma di risolverli costruttivamente. Dovreste sempre tornare alla comunità ed ai suoi processi per cercare consigli e risolvere disaccordi. Ci sono sia il Technical Board che il Community Council che vi aiuteranno a decidere il giusto corso di Ubuntu. Ci sono inoltre diversi Project Teams e Team Leaders, che vi aiuteranno a capire quale direzione potrebbe essere la più accettabile. Se alla fine volete comunque prendere una strada diversa, vi invitiamo a fornire una diversa distribuzione o un set di pacchetti alternativo usando la struttura dell'Ubuntu Package Management, affinchè la comunità possa comunque provare i vostri cambiamenti e le vostre idee, e contribuire alla discussione. Quando non siete sicuri, chiedete. Nessuno sa tutto, e nessuno si aspetta che l'altro sia perfetto nella comunità Ubuntu. Rivolgere domande evita molti problemi lungo il percorso, e quindi le domande sono incoraggiate. Coloro che devono rispondere, dovranno essere reattivi e di grande aiuto. Comunque, nel porre una domanda, occorre avere cura nel rivolgersi al forum appropriato. Domande fuori-tema, come ad esempio una richiesta di supporto in una mailing list di sviluppo distoglie da una discussione produttiva. Lasciate con considerazione. Gli sviluppatori di ogni progetto vanno e vengono, e per Ubuntu non è diverso. Quando lasciate un progetto, del tutto o in parte, fatelo cercando di minimizzare le ripercussioni sul progetto stesso. Ciò significa che dovreste avvisare prima di lasciare e intraprendere le opportune azioni per assicurare che gli altri possano riprendere dal punto da voi lasciato.
23. CODICE DI CONDOTTA Siate premurosi. Siate rispettosi . Lasciate con considerazione. consultate gli altri . chiedete . Siate collaborativi .
24. Ciclo di sviluppo Bug Triage Paolo Sammicheli <xdatap1@ubuntu.com> Andrea Colangelo <warp10@ubuntu.com>
33. RSS IRC ML RICERCA DI SEGNALAZIONI DOPPIE SEGNALAZIONE DUPLICATI
34. RSS IRC ML RICERCA DI SEGNALAZIONI DOPPIE SEGNALAZIONE DUPLICATI COMPLETAMENTO
35. RSS IRC ML VERSIONI CONFIGURAZIONI AZIONI PER RIPRODURLO RISULTATI ATTESI/OTTENUTI RICERCA DI SEGNALAZIONI DOPPIE SEGNALAZIONE DUPLICATI COMPLETAMENTO
36. RSS IRC ML VERSIONI CONFIGURAZIONI AZIONI PER RIPRODURLO RISULTATI ATTESI/OTTENUTI RICERCA DI SEGNALAZIONI DOPPIE SEGNALAZIONE DUPLICATI COMPLETAMENTO RIPRODUCIBILITÀ
37. RSS IRC ML VERSIONI CONFIGURAZIONI AZIONI PER RIPRODURLO RISULTATI ATTESI/OTTENUTI DOCUMENTARE SUCCESSI O INSUCCESSI DI TENTATIVI DI RIPRODUZIONE RICERCA DI SEGNALAZIONI DOPPIE SEGNALAZIONE DUPLICATI COMPLETAMENTO RIPRODUCIBILITÀ
38. RSS IRC ML VERSIONI CONFIGURAZIONI AZIONI PER RIPRODURLO RISULTATI ATTESI/OTTENUTI DOCUMENTARE SUCCESSI O INSUCCESSI DI TENTATIVI DI RIPRODUZIONE RICERCA DI SEGNALAZIONI DOPPIE SEGNALAZIONE DUPLICATI COMPLETAMENTO RIPRODUCIBILITÀ CONFERMA
39. RSS IRC ML VERSIONI CONFIGURAZIONI AZIONI PER RIPRODURLO RISULTATI ATTESI/OTTENUTI DOCUMENTARE SUCCESSI O INSUCCESSI DI TENTATIVI DI RIPRODUZIONE RICERCA DI SEGNALAZIONI DOPPIE SEGNALAZIONE o LINK UPSTREAM RICERCA PATCH VERIFICA SE AFFLIGGE ALTRE DISTRO SEGNALAZIONE DUPLICATI COMPLETAMENTO RIPRODUCIBILITÀ CONFERMA
82. Ciclo di sviluppo DOMANDE ? Paolo Sammicheli <xdatap1@ubuntu.com> Andrea Colangelo <warp10@ubuntu.com>
Editor's Notes
Ubuntu Party 2011 Schio, Palazzo Toaldi Capra 1 Maggio 2011
Salve a tutti e benvenuti! Oggi vedremo come partecipare al ciclo di sviluppo di Ubuntu.
Due parole su di me, mi chiamo Paolo Sammicheli , sono un informatico di professione e, nel tempo libero, partecipo allo sviluppo di Ubuntu. In Ubuntu mi occupo di diverse cose. Con il gruppo italiano mi occupo di Traduzioni, di Marketing e Comunicazione ed inoltre coordino il gruppo italiano di Quality Assurance, ovvero facciamo i test del software in corso di sviluppo. Io invece sono Andrea Colangelo , studio Ingegneria Informatica e anche io nel tempo libero sono coinvolto in Ubuntu. Sono un Ubuntu Developer da oltre tre anni, e mi occupo in particolare di Quality Assurance e di pacchetti in Python. Sono attivo nella comunità italiana nel Gruppo Promozione, in particolare nella newsletter, nel Progetto CD e nel Progetto Relatori.
Intanto una buona notizia. Non avete da prendere appunti. Le slide che vi mostreremo, complete di note con quello che diciamo sono già online a questo indirizzo.
Vediamo intanto che cosa è Ubuntu per chi non avesse partecipato al talk di ieri.
Ubuntu è innanzitutto un'antica parola Africana dal significato molto profondo.
«Io sono ciò che sono per merito di ciò che siamo tutti» è una traduzione di questa parola. Richiama il genere umano allo spirito di comunità anziché di individualismo.
Ma Ubuntu è anche una distribuzione GNU/Linux.
Ubuntu è stata fondata da Mark Shuttleworth, giovane imprenditore Sud Africano che nel 1999 ha venduto la propria azienda, Thawte ad una grossa azienda americana, Verisign, guadagnando 575 Milioni di Dollari Americani. E cosa fa, secondo voi, un “ragazzo” di 26 anni con in mano 575 Milioni di Dollari? Beh, Mark si è pagato un viaggio nello spazio, è stato il secondo turista nello spazio. Qui lo vedere dentro la stazione spaziale internazionale.
La comunità di Ubuntu è una comunità internazionale formata da Volontari e professionisti che collaborano per creare la distribuzione e da un'azienda: Canonical (http://www.canonical.com). Canonical è l'azienda fondata da Mark per sponsorizzare lo sviluppo di Ubuntu.
Esistono poi delle organizzazioni nazionali, chiamati LoCo Team, ovvero Local Community. Sono uno per ogni stato negli Stati Uniti e uno per ogni nazione nel resto del mondo. Quella che vedete è la foto di un meeting della comunità Italiana. Ulteriori informazioni: http://www.ubuntu-it.org
Due parole sulla comunità Italiana: Ubuntu-it ha un sito raggiungibile all'indirizzo www.ubuntu-it.org o anche www.ubuntu.it .
Che cosa offre Ubuntu-it? Innanzitutto Supporto Tecnico agli utenti tramite molti strumenti: Forum, Mailing List, wiki, Irc, ecc. Ulteriori informazioni: http://www.ubuntu-it.org/index.php?page=supporto-della-comunita
Inoltre ci occupiamo di tradurre in Italiano il Software, oltre che molti documenti e articoli. Inolte traduciamo anche una rivista dedicata ad Ubuntu: Full Circle Magazine. La potete scaricare liberamente dal sito. Ulteriori informazioni: http://wiki.ubuntu-it.org/GruppoTraduzione
E produciamo documentazione tecnica e guide in Italiano, sia traducendola dall'inglese che scrivendone di originali. Tutte le guide sono sul wiki. Sapete cosa è un wiki vero? È il motore che anima anche wikipedia. È un sito web che tutti possono modificare. Ulteriori informazioni: http://wiki.ubuntu-it.org/GruppoDocumentazione
E ci occupiamo della promozione e diffusione di Ubuntu, come ad esempio andare a delle conferenze e parlare di noi :) Ulteriori informazioni: http://wiki.ubuntu-it.org/GruppoPromozione
Inoltre partecipiamo con la comunità internazionale nello sviluppo della distribuzione stessa e nei test per cercare di migliorare i programmi che compongono Ubuntu. Ulteriori informazioni: http://wiki.ubuntu-it.org/GruppoSviluppo http://wiki.ubuntu-it.org/GruppoTest
La comunità è divisa in gruppi di lavoro, che sono coordinati dal Consiglio della Comunità. Ulteriori informazioni: http://www.ubuntu-it.org/contribuire/Struttura_Com.shtml
Vediamo adesso come partecipare alla comunità di Ubuntu. La prima cosa da fare è aprire i propri account e preparare la pagina personale sul wiki. In pratica è un modo per essere riconoscibili all'interno della comunità. Considerate che la comunità di Ubuntu è molto vasta, quindi è difficile ricordarsi di tutti a memoria. La vostra pagina personale parla di voi e vi presenta agli altri.
Vi viene anche chiesto, come prima cosa, di firmare il Codice di Condotta di Ubuntu con una chiave crittografica.
Questo è il codice di condotta di Ubuntu, come vedete è un po' lunghetto.
Non vi fate spaventare dalla lunghezza, il codice di condotta è abbastanza semplice e può essere sintetizzato con alcune parole chiave.
Questi sono gli inviti che il codice di condotta fa a chi è membro della comunità Ubuntu. Come vedete sono principi semplici e condivisibili ma contraddistinguono lo stile con cui la comunità Ubuntu si pone alle cose. Una comunità serena ed in armonia è anche una comunità produttiva. Il codice di condotta vuole mantenere un bel clima di rispetto all'interno della comunità.
Ieri abbiamo visto come segnalare un BUG. Vediamo adesso il processo che porta un bug dalla sua segnalazione fino alla sua approvazione per essere sottoposto ai gruppi di sviluppo. Cosa significa, quindi, TRIAGE?
Più o meno tutti abbiamo avuto la sfortuna di andare in ospedale, per noi stessi o per accompagnare qualcuno. Se non si trattava di una visita programmata siamo dovuti passare dal Pronto Soccorso.
Al Pronto Soccorso viene svolta una procedura chiamata TRIAGE. In pratica si tratta di identificare i pazienti in arrivo, decidere dove devono andare e fornirgli una priorità in base all'urgenza del loro trattamento.
La stessa cosa la facciamo con gli odiati BUG. Il Triage dei Bug viene condotto per buona parte dai volontari della comunità Internazionale. Anche voi potete partecipare al triage dei bug sveltendo cosi' la loro correzione e migliorando Ubuntu.
Perché è necessario eseguire un Triage di un Bug? Come avviene per le prestazioni sanitarie non è possibile aggredire e risolvere tutti i problemi quando si presentano. Si forma in maniera naturale una sorta di fila di attesa.
Il triage permette di catalogare i pazienti in attesa in modo che i casi più urgenti vengano serviti prima. Vediamo i passi che si deve svolgere per fare il triage dei Bug in Ubuntu.
Innanzitutto, per fare il Triage vorremmo vedere l'elenco dei bug che vengono segnalati. Essi si trovano su Launchpad
e le informazioni circa le nuove segnalazioni vengono propagate anche in altri canali, come i feed rss, il canale IRC e una mailing list apposita.
Iniziando a trattare un Bug, per prima cosa è utile determinare se la segnalazione è riferita ad un bug già segnalato precedentemente.
Questo per evitare di fare un lavoro doppio.
Dopodiché dobbiamo aiutare l'utente, tramite una sorta di dialogo che avviene nei commenti del bug, a completare la segnalazione, in modo che tutte le informazioni necessarie siano state scritte nella segnalazione di Bug.
Ad esempio è importante avere informazioni sulle versioni, sulle configurazioni e sui passi da compiere per riprodurlo.
Quindi, coloro che effettuano il Triage di un Bug proveranno a riprodurlo.
Documentando i loro risultati. Sono utili anche risultati di insuccesso nella riproduzione in quanto possono indicare informazioni ulteriori. Ad esempio, se il bug è dipendente da un particolare componente hardware.
Se tutte le informazioni sono state inserite sul bug possiamo quindi confermarlo.
Con la conferma del bug si inizia a collegarlo con il resto del mondo. Ad esempio è importante, sui bug confermati, verificare se non sono già stati segnalati upstream e nel caso fossero di pertinenza è utile aprire la segnalazione anche là. Launchpad permette di inserire link ad altri gestori di Bug dei progetti da cui Ubuntu deriva (Debian, Mozilla, GNOME, KDE, ecc). Inoltre, specie per i Bug di sicurezza, è importante fare ricerche su altre distribuzioni, anche se non facenti parti della catena di produzione di Ubuntu, in modo da avere una collaborazione più efficace.
Quando si inizia ad imparare a fare il Triage una delle prime difficoltà è che non si sa cosa rispondere a chi ha aperto il Bug. Come ricordate il Codice di Condotta ci chiede di essere gentili, e la forma è importante nel comunicare con gli utenti che ci segnalano bug.
Ma per fortuna abbiamo una risorsa molto utile, le risposte tipo catalogate per categoria: https://wiki.ubuntu.com/Bugs/Responses È una pagina molto lunga e viene aggiornata anche abbastanza spesso. Non esitate a consultarla ogni volta che dovete fare il Triage di un BUG.
Altro problema è individuare il pacchetto giusto a cui associare il BUG. Anche qui c'è una risorsa molto importante: https://wiki.ubuntu.com/Bugs/FindRightPackage Come la pagina precedente è molto lunga, non si presta ad essere imparata a memoria. Va seguita ogni volta alla ricerca delle informazioni corrette. Inoltre varia frequentemente, in funzione dei cambiamenti che si presentano nella distribuzione stessa. Chi è interessato al Triage troverà utile sottoscrivere quella pagina in modo da ricevere mail sulle modifiche che vengono apportate.
E, come vi dicevo, i Bug in Launchpad possono essere collegati a Bug in altri sistemi di tracciatura in modo da avere un collegamento, ed una sincronizzazione, con Upstream e le altre distribuzioni. Qui vedete un esempio di un bug del Kernel collegato con Debian e con il gruppo di lavoro del Kernel stesso.
Comunque sia, capiterà di trovarvi nel dubbio di cosa fare. Fare il Triage dei BUG è un tema molto vasto e non si può sapere tutto di tutto. Però il Codice di Condotta ci dice che “Quando non siete sicuri, chiedete”. Non c'è niente di male a chiedere aiuto o un parere agli altri.
Per coloro che svolgono il Triage c'è la mailing list della Bugsquad: https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
E, per risposte rapide, un canale IRC sulla rete freenode.net: #ubuntu-bugs
Vediamo adesso come funziona il packaging dei programmi in Ubuntu e come possiamo correggere un bug applicando una patch al pacchetto individuato durante il processo di Triage.
A differenza di altri sistemi operativi, in Ubuntu è possibile installare software in maniera semplice prelevandolo da un archivio centrale gestito dagli Ubuntu Developer. Questo consente una grande quantità di vantaggi: - facilità di installazione - upgrade facile - riduzione del rischio di infettare il sistema con virus, malware e altro - gestione automatica delle dipendenze - rimozione semplice senza lasciare tracce in giro.
Un pacchetto binario, con estensione .deb, contiene i binari compilati e gli altri file del programma in una gerarchia di directory analoga a quella del sistema su cui il programma sarà installato. Dpkg non fa altro che estrarre i file da lì e copiarli nel sistema nella posizione giusta. Inoltre, ogni pacchetto contiene una serie di informazioni, note come meta-dati, necessarie per gestire le dipendenze, le versioni, gli upgrade, etc.
Il lavoro del maintainer di pacchetti si concentra in realtà nel 99% dei casi sul source package, che è il pacchetto contenente il software del programma e le modifiche che il packager ha apportato per consentire la pacchettizzazione stessa. Pertanto, è indispensabile capire com'è fatto un source package per poterci lavorare.
Un pacchetto sorgente è in realtà composto da 3 file distinti: - un file .orig.tar.gz, che è la tarball del software originale (tipicamente senza alcuna modifica) - un file .dsc che contiene metadati necessari alla corretta gestione del source package, inclusi i checksum sha1 e sha256 di tutti e tre i file e la firma GPG dell'ultima persona che ha lavorato sul pacchetto - un file .diff.gz (o .debian.gz nel formato più recente dei source package, il 3.0) che è una patch applicata al file .orig.tar.gz contenente tutte le modifiche necessarie per il packaging. Tipicamente queste modifiche sono tutte raccolte in una serie di file inseriti all'interno di una cartella di nome debian/ che è inserita nel source tree del codice sorgente.
All'interno del file diff ci sono quindi i file necessari al packaging dell'applicazione, inseriti all'interno della cartella debian/. Il numero di questi file dipende dalla complessità del packaging stesso. Tuttavia, 4 di questi file sono obbligatori e devono essere sempre presenti. Vediamoli rapidamente.
Iil file “control” è probabilmente il più importante dei 5. Contiene tutte le metainformazioni necessarie al build del pacchetto e alla sua catalogazione in archivio, oltre alla descrizione che sarà mostrata all'utente in synpatic o nell'Ubuntu Software Center. Contiene una stanza per il source package, e una stanza per ogni binary package che viene generato durante il build. Campi tipici includono il nome del pacchetto, l'elenco delle dipendenze di build, il nome del Maintainer, la homepage del software upstream, etc.
Il file “changelog” contiene l'elenco delle modifiche che sono apportate al packaging nel corso del tempo. Il numero di versione del pacchetto è registrato in questo file.
Il file “compat” contiene solo un numero, che rappresenta il livello di compatibilità con debhelper, una suite di tool utilizzati per il build del pacchetto. In effetti, questo file non è strettamente obbligatorio, ma è necessario se ci si avvale delle potenzialità offerte da debhelper. La grande maggioranza dei pacchetti che compongono l'archivio utilizza effettivamente debhelper
Il file “copyright” è un file particolarmente delicato che deve essere compilato con grande cura. Contiene tutte le informazioni legate al copyright e alla licenza del software originale. Un “copyright” compilato in maniera errata può impedire al pacchetto di entrare in archivio (o causarne la eliminazione) per motivi legali.
Infine, il file “rules” è un banale Makefile che contiene le istruzioni per il build del pacchetto. Può essere estremamente breve o molto lungo in base alla complessità del pacchetto stesso.
A questo possiamo metterci al lavoro e risolvere il nostro primo bug!
Non tutti i bug sono creati uguali. Scegliere il bug giusto è una decisione che combina gusti personali, conoscenze tecniche, difficoltà e altro ancora.
Per questa dimostrazione scegliamo un bug particolarmente grave che coinvolge Unity, l'interfaccia grafica di Ubuntu
Prendiamo il terminale, creiamo una cartella in cui lavorare e scarichiamo il source package di unity con apt-get
Dopo breve tempo, apt-get scaricherà i sorgenti e preparerà un source tree su cui lavorare. Vediamo in dettaglio che cos'ha fatto.
Prima di tutto, apt-get ci avvisa che il packaging di unity è gestito anche tramite bzr, un sistema di controllo delle versione che sarà sempre più usato in Ubuntu perchè consente una gestione migliore del codice.
Successivamente, apt-get scarica i 3 file che compongono il source package.
Infine, apt-get decomprime il file .orig.tar.gz e applica la patch contenuta nel file .diff.gz
Alla fine delle operazioni vediamo che apt-get ha salvato nella cartella i 3 file del source package e ha preparato una cartella contenente il source tree
Entriamo ora nella directory che apt-get ha creato per noi: il contenuto è quello del file .orig.tar.gz (ovvero della tarball originale), con l'aggiunta della cartella debian/ e dei file in essa contenuti, come indicato nel file .diff.gz
La cartella debian/ contiene i 5 file obbligatori di cui abbiamo parlato e altri che sono necessari per questo particolare pacchetto.
A questo punto siamo pronti per cominciare.
Risolvere il bug è la parte più amata ed odiata dell'intero processo: amata perchè risolvere bug è un'attività stimolante e divertente, odiata perchè non sempre le cose vanno come speriamo e magari bisognerà fare diversi tentativi prima di arrivare al risultato desiderato. In generale, i bug possono riguardare il packaging o il codice sorgente del programma. In entrambi i casi, strategie differenti dovranno essere utilizzate a seconda dei casi. L'esperienza e le conoscenze tecniche sapranno dirimenti. In realtà, un buon maintainer deve essere anche un buon comunicatore, destreggiandosi tra le richieste e le esigenze (spesso contrapposte) dell'utente, dei colleghi MOTU, dei Debian Developer e dello sviluppatore upstream.
Dopo aver trovato il problema e fatto il nostro fix, scriviamo una breve nota nel file changelog per documentare il lavoro fatto. In questo caso specifico, trascuriamo volutamente la parte relativa al fix in sé, che fingiamo sia data per scontata, e ci concentriamo in maniera specifica sulle procedure legate al packaging.
Il numero di versione viene ovviamente aumentato...
… e si aggiunge questo tag magico che chiuderà automaticamente il bug quando il pacchetto sarà stato compilato e pubblicato in archivio
A questo punto possiamo creare il source package contenente il nostro fix.
Dopo pochi secondi, debuild restituirà il source package, debitamente firmato con la chiave GPG dello svilluppatore.
Ora nella cartella esterna abbiamo un file .dsc e un file .diff.gz del nostro nuovo source package. Poichè il file .orig.tar.gz non è stato modificato, non c'è bisogno di ricrearlo, ed è quello che apt-get aveva scaricato per noi.
A questo punto usiamo di nuovo debuild per creare il pacchetto binario. In realtà, un buon maintainer preferirebbe usare un programma come pbuilder che consente di creare una chroot pulita e minimale dentro la quale compilare il pacchetto, per una serie di ragioni tecniche. Per ora, ignoriamo questa buona pratica.
Dopo qualche minuto (o perfino qualche ora!) debuild completa la sua esecuzione ed ecco che un file .deb appare nella cartella esterna. Ora possiamo installare questo file sul sistema e assicurarci che il nostro fix risolva il problema (senza introdurne di nuovi!)
L'ultimo passaggio consiste nell'utilizzare dput per caricare il source package nell'archivio. Il pacchetto sarà compilato, pubblicato e il bug report di LP sarà chiuso automaticamente.
Missione compiuta!
Chiunque può partecipare allo sviluppo di Ubuntu. Questi tre link sono tre ottimi punti di partenza per approfondire le tematiche tecniche o per scoprire come cominciare a contribuire nel packaging.
Ubuntu Party 2011 Schio, Palazzo Toaldi Capra 1 Maggio 2011