DOCSLIB.ORG

Large Scale Bug Tracking and Interoperability of Development Tools in the FLOSS Ecosystem

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Large Scale Bug Tracking and Interoperability of Development Tools in the FLOSS Ecosystem Introduction Interlinking bug reports Current efforts More on OSLC Conclusion Large scale bug tracking and interoperability of development tools in the FLOSS ecosystem Olivier Berger <[email protected]> - Télécom SudParis Jeudi 09/06/2011 Séminaire IRILL Olivier Berger <[email protected]> - Télécom SudParis Large scale bug tracking and interoperability of development tools in the FLOSS ecosystem Introduction Interlinking bug reports Current efforts More on OSLC Conclusion Purpose Apologies / Excuses Mélange de transparents en anglais et français. Toutes mes excuses, all my apologies in advance, par avance. Olivier Berger <[email protected]> - Télécom SudParis Large scale bug tracking and interoperability of development tools in the FLOSS ecosystem Introduction Interlinking bug reports Current efforts More on OSLC Conclusion Purpose Large scale bugtracking Definition : bugtracking NO : Looking for bugs in the code / programs YES : Looking for bug reports for these bugs Olivier Berger <[email protected]> - Télécom SudParis Large scale bug tracking and interoperability of development tools in the FLOSS ecosystem Introduction Interlinking bug reports Current efforts More on OSLC Conclusion Purpose as @zack said Source : http ://git.upsilon.cc/r/talks/20110224-evry.git Olivier Berger <[email protected]> - Télécom SudParis Large scale bug tracking and interoperability of development tools in the FLOSS ecosystem Introduction Interlinking bug reports Current efforts More on OSLC Conclusion Purpose Large scale : FLOSS ecosystem Lots of duplicate or related bug reports Not a single place where to monitor bugs OK, launchpad, maybe. too much a silo anyway No interoperability of tools Manual work of maintainer / QA (bug triaging, etc.) Olivier Berger <[email protected]> - Télécom SudParis Large scale bug tracking and interoperability of development tools in the FLOSS ecosystem Introduction Interlinking bug reports Current efforts More on OSLC Conclusion Purpose Who I am Since 2002 : Institut TELECOM / TELECOM SudParis / Computer Science dept. / PFTCR team Research on collaborative development platforms, tools, process, in FLOSS communities Previously worked in service companies (Cap Gemini, IDEALX) R&D on FLOSS, forges, bugtracking, Linked Data, etc. (CALIBRE, HELIOS, COCLICO) (recent) Debian developer (obergix), contributor to FusionForge, etc. Olivier Berger <[email protected]> - Télécom SudParis Large scale bug tracking and interoperability of development tools in the FLOSS ecosystem Introduction Interlinking bug reports Current efforts More on OSLC Conclusion About our recent collaborations About HELIOS (over now) Application Lifecycle Management with Open Source tools System@tic Paris Region http: Partners : Alcatel-Lucent, Artenum, //heliosplatform. TELECOM SudParis, Kalis, sourceforge.net/ Mandriva, Thales First work on bugtracker interoperability OSLC, MantisBT, bts-link, UDD, Linked Data Olivier Berger <[email protected]> - Télécom SudParis Large scale bug tracking and interoperability of development tools in the FLOSS ecosystem Introduction Interlinking bug reports Current efforts More on OSLC Conclusion About our recent collaborations COCLICO (ongoing) http://www.projet-coclico.org/ Le projet COCLICO vise à redynamiser les communautés de forges logicielles en structurant un écosystème libre pour lequel il existe une masse critique d’acteurs en France. Olivier Berger <[email protected]> - Télécom SudParis Large scale bug tracking and interoperability of development tools in the FLOSS ecosystem Introduction Interlinking bug reports Current efforts More on OSLC Conclusion About our recent collaborations Financeurs Pôles de compétitivité System@tic (Paris) Minalogic (Grenoble) Financement public (partiel) 2 ans (2009-2011) Olivier Berger <[email protected]> - Télécom SudParis Large scale bug tracking and interoperability of development tools in the FLOSS ecosystem Introduction Interlinking bug reports Current efforts More on OSLC Conclusion About our recent collaborations Partenaires 9 participants principalement à Paris et Grenoble Industriels : Bull, Orange Labs, Xerox PMEs : CELI France, Bearstech, Gnurandal (via Xerox), Objet Direct Academiques : INRIA, Institut TELECOM / Télécom Sud Paris Centrage fort sur le logiciel libre (est-ce que ça ne devrait pas être toujours comme cela avec du financement public ?) Olivier Berger <[email protected]> - Télécom SudParis Large scale bug tracking and interoperability of development tools in the FLOSS ecosystem Introduction Interlinking bug reports Current efforts More on OSLC Conclusion About our recent collaborations Objectifs du projet COCLICO (quoting its website) Re-dynamisation de la communautés logiciel libre des développeurs autour de la base de code historique des forges libres (FusionForge et Codendi) Définition d’un modèle d’intégration ouvert Intégrité des données et confidentialité Échange de données en temps réel entre les différentes forges Fonctionnalités pour utilisation industrielle et assurance qualité traçabilité des informations, support de méthodologies de génie logiciel, interaction avec le poste de travail du développeur. etc. Olivier Berger <[email protected]> - Télécom SudParis Large scale bug tracking and interoperability of development tools in the FLOSS ecosystem Introduction Interlinking bug reports Current efforts More on OSLC Conclusion Problem definition The need for interlinked bug reports Help developers, maintainers, power users Monitoring work done around particular issues Not one single distribution channel Many venues for support : many distributions, many bugtrackers Redundancy of reports across trackers Final goal : ease of monitoring bug reports links all over the FLOSS ecosystem Olivier Berger <[email protected]> - Télécom SudParis Large scale bug tracking and interoperability of development tools in the FLOSS ecosystem Introduction Interlinking bug reports Current efforts More on OSLC Conclusion Problem definition Existing tools : bts-link http://bts-link.alioth.debian.org/ Monitoring status changes on upstream bugs around the Debian bugtracker Debian tool for package maintainers (and advanced users) Uses existing bug links (forwarded-to) set by humans : Distribution (Debian) package bugs “Upstream” project bugtrackers bugs Email notification for Debian packagers (or people monitoring Debian bugs) Supports lots of upstream bugtracker types (through specific connectors) : bugzilla (and issuezilla), gnats, launchpad, mantis, savane (from savanah), sourceforge trackers, trac, gforge (and fusionforge most probably), google code Olivier Berger <[email protected]> - Télécom SudParis Large scale bug tracking and interoperability of development tools in the FLOSS ecosystem Introduction Interlinking bug reports Current efforts More on OSLC Conclusion Problem definition Existing tools : Eclipse Mylyn http://www.eclipse.org/mylyn/ Mylyn Tasks (many other modules) Offers integrated bug tracking interfaces inside Eclipse Supports contexts attached to bug reports 32 different connectors to bugtrackers to maintain Olivier Berger <[email protected]> - Télécom SudParis Large scale bug tracking and interoperability of development tools in the FLOSS ecosystem Introduction Interlinking bug reports Current efforts More on OSLC Conclusion Problem definition Existing tools : SD (Simple defects) http://syncwith.us/sd/ Distributed bugtracking. Think : Bugzilla == Subversion SD == Git (+ git-svn, etc.) CLI interface ;-) Again, many connectors needed to different bug trackers (RT, Hiveminder, Trac, GitHub, Google Code, Redmine, debbugs ?) Internal common representation (bug properties common base -> OSLC-CM) ? Olivier Berger <[email protected]> - Télécom SudParis Large scale bug tracking and interoperability of development tools in the FLOSS ecosystem Introduction Interlinking bug reports Current efforts More on OSLC Conclusion Problem definition Issues for such tools Needs custom ad-hoc connectors/scrapers for each bugtracker : no standard APIs Proliferation Not always very actively maintained (including bugtrackers) Olivier Berger <[email protected]> - Télécom SudParis Large scale bug tracking and interoperability of development tools in the FLOSS ecosystem Introduction Interlinking bug reports Current efforts More on OSLC Conclusion Past efforts Problems : interop / standardisation (lack of -) Until recently, no real standard for bugtrackers : APIs / protocols Interchange of (meta-)data representing Bugs/Issues (and associate resources) Old school technology (Web 1.5 ?) : mashups difficult, ambiguous URIs, etc. Olivier Berger <[email protected]> - Télécom SudParis Large scale bug tracking and interoperability of development tools in the FLOSS ecosystem Introduction Interlinking bug reports Current efforts More on OSLC Conclusion Past efforts Past efforts : our Helios_BT ontology PhD work as part of Helios project Bug/Issue representation Ontology, Schema (Semantic Web standards) Contributed to standardisation effort : baetle project http ://code.google.com/p/baetle/ (dead now) Reuse of EvoOnt BOM http ://www.ifi.uzh.ch/ddis/evo/ Semantic web techniques (RDF) : extensible Mapping bugtrackers data to RDF/Linked Data : prototype on UDD, bugzilla, etc. (D2R) TODO : Need to adjust to OSLC-CM that appeared in between Olivier Berger <[email protected]> - Télécom SudParis Large scale bug
Load more

Recommended publications
  • Debian Developer's Reference Version 12.0, Released on 2021-09-01
    Debian Developer’s Reference Release 12.0 Developer’s Reference Team 2021-09-01 CONTENTS 1 Scope of This Document 3 2 Applying to Become a Member5 2.1 Getting started..............................................5 2.2 Debian mentors and sponsors......................................6 2.3 Registering as a Debian member.....................................6 3 Debian Developer's Duties 9 3.1 Package Maintainer's Duties.......................................9 3.1.1 Work towards the next stable release............................9 3.1.2 Maintain packages in stable .................................9 3.1.3 Manage release-critical bugs.................................. 10 3.1.4 Coordination with upstream developers............................ 10 3.2 Administrative Duties.......................................... 10 3.2.1 Maintaining your Debian information............................. 11 3.2.2 Maintaining your public key.................................. 11 3.2.3 Voting.............................................. 11 3.2.4 Going on vacation gracefully.................................. 12 3.2.5 Retiring............................................. 12 3.2.6 Returning after retirement................................... 13 4 Resources for Debian Members 15 4.1 Mailing lists............................................... 15 4.1.1 Basic rules for use....................................... 15 4.1.2 Core development mailing lists................................. 15 4.1.3 Special lists........................................... 16 4.1.4 Requesting new
    [Show full text]
  • Code Distribution Process - Definition of Evaluation Metrics
    Code Distribution Process - Definition of Evaluation Metrics Project Acronym Edos Project Full Title Environment for the Development and Distribution of Open Source Software Project # FP6-IST-004312 Contact Author Radu POP, [email protected] Authors List Ciaran Bryce, Michel Pawlak, Michel Deriaz - Universite de Geneve Serge Abiteboul, Boris Vrdoljak - INRIA Gemo Project Tova Milo, Assaf Sagi - Tel-Aviv University Stephane Lauriere, Florent Villard, Radu POP - MandrakeSoft Workpackage # WP 4 Deliverable # 1 Document Type Report Version 1.0 Date March 22, 2005 Distribution Consortium, Commission and Reviewers. Chapter 1 Introduction This document proposes a measurement and evaluation methodology and defines the metrics that we consider as important in EDOS for the code distribution process for Free and Open Source Software (F/OSS). Our aim in attempting to define the metrics is the following: Clarify our understanding of the F/OSS code distribution process, and • subsequently to help identify areas for improvement. Enumerate what needs to be measured in the F/OSS code distribution • process. The purpose of measurement and evaluation is to compare different architectures for code distribution the existing one and those that will be proposed in the EDOS project. Measurement and evaluation have been facets of software engineering for some time. ISO (the International Organisation for Standardisation) and IEC (the International Electrotechnical Commision) have established a joint technical committee for worldwide standardization in the field of information technology. They have developed a set of standards for software product quality relating to the definition of quality models (the 9126 series) and to the evaluation process (the 14598 series). A quality model defines the characteristics of a system to be measured and the metrics that evaluate how the system to be measured performs with respect to these characteristics.
    [Show full text]
  • A Case Study on Software Vulnerability Coordination
    A Case Study on Software Vulnerability Coordination Jukka Ruohonena,∗, Sampsa Rautia, Sami Hyrynsalmia,b, Ville Lepp¨anena aDepartment of Future Technologies, University of Turku, FI-20014 Turun yliopisto, Finland bPori Department, Tampere University of Technology, P.O. Box 300, FI-28101 Pori, Finland Abstract Context: Coordination is a fundamental tenet of software engineering. Coordination is required also for identifying discovered and disclosed software vulnerabilities with Common Vulnerabilities and Exposures (CVEs). Motivated by recent practical challenges, this paper examines the coordination of CVEs for open source projects through a public mailing list. Objective:The paper observes the historical time delays between the assignment of CVEs on a mailing list and the later appearance of these in the National Vulnerability Database (NVD). Drawing from research on software engineering coordination, software vulnerabilities, and bug tracking, the delays are modeled through three dimensions: social networks and communication practices, tracking infrastructures, and the technical characteristics of the CVEs coordinated. Method: Given a period between 2008 and 2016, a sample of over five thousand CVEs is used to model the delays with nearly fifty explanatory metrics. Regression analysis is used for the modeling. Results: The results show that the CVE coordination delays are affected by different abstractions for noise and prerequisite constraints. These abstractions convey effects from the social network and infrastructure dimensions. Particularly strong effect sizes are observed for annual and monthly control metrics, a control metric for weekends, the degrees of the nodes in the CVE coordination networks, and the number of references given in NVD for the CVEs archived. Smaller but visible effects are present for metrics measuring the entropy of the emails exchanged, traces to bug tracking systems, and other related aspects.
    [Show full text]
  • Gestión De Proyectos Software
    Proyecto Fin de Carrera AITForge: Gestión de Proyectos Software Autor: Antonio Domingo Lagares Alfaro Titulación: Ingeniero de Telecomunicación (Plan 98) Especialidad: Telemática Año: 2005 Tutor: Antonio Estepa Alonso AITForge: Gestión de Proyectos Software Índice de contenido 1 Prefacio..................................................................................................................6 2 Portales de Desarrollo Colaborativo......................................................................7 2.1 Introducción a los Entornos Colaborativos....................................................8 2.1.1 Hosting de Proyectos de Software Libre (FOSPHost)...........................9 2.1.2 ¿Software Libre y Software de Fuentes Abiertas?...............................10 2.1.3 Prácticas deseables en Software Libre................................................11 2.1.4 El nacimiento de una nueva filosofía de trabajo...................................13 2.1.5 Objetivos de los sistemas libres de FOSPHost....................................14 2.1.6 Principales características de los sistemas FOSPHost........................16 Características intrínsecas..........................................................................16 Características de utilidad...........................................................................17 Características de usabilidad......................................................................18 Características contextuales.......................................................................19 2.1.7
    [Show full text]
  • Free Software Needs Free Tools
    Free Software Needs Free Tools Benjamin Mako Hill [email protected] June 6, 2010 Over the last decade, free software developers have been repeatedly tempted by devel- opment tools that offer the ability to build free software more efficiently or powerfully. The only cost, we are told, is that the tools themselves are nonfree or run as network services with code we cannot see, copy, or run ourselves. In their decisions to use these tools and services – services such as BitKeeper, SourceForge, Google Code and GitHub – free software developers have made “ends-justify-the-means” decisions that trade away the freedom of both their developer communities and their users. These decisions to embrace nonfree and private development tools undermine our credibility in advocating for soft- ware freedom and compromise our freedom, and that of our users, in ways that we should reject. In 2002, Linus Torvalds announced that the kernel Linux would move to the “Bit- Keeper” distributed version control system (DVCS). While the decision generated much alarm and debate, BitKeeper allowed kernel developers to work in a distributed fashion in a way that, at the time, was unsupported by free software tools – some Linux developers decided that benefits were worth the trade-off in developers’ freedom. Three years later the skeptics were vindicated when BitKeeper’s owner, Larry McVoy, revoked several core kernel developers’ gratis licenses to BitKeeper after Andrew Tridgell attempted to write a free replacement for BitKeeper. Kernel developers were forced to write their own free software replacement: the project now known as Git. Of course, free software’s relationships to nonfree development tools is much larger than BitKeeper.
    [Show full text]
  • GNAT User's Guide
    GNAT User's Guide GNAT, The GNU Ada Compiler For gcc version 4.7.4 (GCC) AdaCore Copyright c 1995-2009 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts and with no Back-Cover Texts. A copy of the license is included in the section entitled \GNU Free Documentation License". About This Guide 1 About This Guide This guide describes the use of GNAT, a compiler and software development toolset for the full Ada programming language. It documents the features of the compiler and tools, and explains how to use them to build Ada applications. GNAT implements Ada 95 and Ada 2005, and it may also be invoked in Ada 83 compat- ibility mode. By default, GNAT assumes Ada 2005, but you can override with a compiler switch (see Section 3.2.9 [Compiling Different Versions of Ada], page 78) to explicitly specify the language version. Throughout this manual, references to \Ada" without a year suffix apply to both the Ada 95 and Ada 2005 versions of the language. What This Guide Contains This guide contains the following chapters: • Chapter 1 [Getting Started with GNAT], page 5, describes how to get started compiling and running Ada programs with the GNAT Ada programming environment. • Chapter 2 [The GNAT Compilation Model], page 13, describes the compilation model used by GNAT. • Chapter 3 [Compiling Using gcc], page 41, describes how to compile Ada programs with gcc, the Ada compiler.
    [Show full text]
  • This Book Doesn't Tell You How to Write Faster Code, Or How to Write Code with Fewer Memory Leaks, Or Even How to Debug Code at All
    Practical Development Environments By Matthew B. Doar ............................................... Publisher: O'Reilly Pub Date: September 2005 ISBN: 0-596-00796-5 Pages: 328 Table of Contents | Index This book doesn't tell you how to write faster code, or how to write code with fewer memory leaks, or even how to debug code at all. What it does tell you is how to build your product in better ways, how to keep track of the code that you write, and how to track the bugs in your code. Plus some more things you'll wish you had known before starting a project. Practical Development Environments is a guide, a collection of advice about real development environments for small to medium-sized projects and groups. Each of the chapters considers a different kind of tool - tools for tracking versions of files, build tools, testing tools, bug-tracking tools, tools for creating documentation, and tools for creating packaged releases. Each chapter discusses what you should look for in that kind of tool and what to avoid, and also describes some good ideas, bad ideas, and annoying experiences for each area. Specific instances of each type of tool are described in enough detail so that you can decide which ones you want to investigate further. Developers want to write code, not maintain makefiles. Writers want to write content instead of manage templates. IT provides machines, but doesn't have time to maintain all the different tools. Managers want the product to move smoothly from development to release, and are interested in tools to help this happen more often.
    [Show full text]
  • Estudos Preliminares
    IGOR BESSA MENEZE PODER JUDICIÁRIO S JOSE MARIO VIANA JUSTIÇA DO TRABALHO BARBOSA JUNIOR LENIVIA TRIBUNAL REGIONAL DO TRABALHO DA 7ª REGIÃO DE CASTRO E SILVA MENDES FRANCISC O JONATHAN SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO REBOUCAS MAIA Estudos Preliminares Contratação de Suporte Técnico, incluindo atualizações evolutivas e corretivas, para a ferramenta Atlassian Jira e Plugins eazyBI Reports and Charts e Git Integration. Estudos Preliminares - Contratação de Suporte Técnico, incluindo atualizações evolutivas e corretivas, para a ferramenta Atlassian Jira e Plugins eazyBI Reports and Charts e Git Integration. 1 PODER JUDICIÁRIO JUSTIÇA DO TRABALHO TRIBUNAL REGIONAL DO TRABALHO DA 7ª REGIÃO SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO Sumário ANÁLISE DE VIABILIDADE DA CONTRATAÇÃO (Art.14) 4 Contextualização 4 Definição e Especificação dos Requisitos da Demanda (Art. 14, I) 5 Requisitos de Negócio 5 Requisitos Técnicos 6 Requisitos Temporais 6 Soluções Disponíveis no Mercado de TIC (Art. 14, I, a) 7 Contratações Públicas Similares (Art. 14, I, b) 10 Outras Soluções Disponíveis (Art. 14, II, a) 11 Portal do Software Público Brasileiro (Art. 14, II, b) 11 Alternativa no Mercado de TIC (Art. 14, II, c) 12 Modelo Nacional de Interoperabilidade – MNI (Art. 14, II, d) 12 Infraestrutura de Chaves Públicas Brasileira – ICP-Brasil (Art. 14, II, e) 12 Modelo de Requisitos Moreq-Jus (Art. 14, II, f) 12 Análise Comparativa dos Custos das Soluções (Art. 14, III) 12 Escolha e Justificativa da Solução (Art. 14, IV) 15 Descrição da Solução (Art. 14, IV,a) 21 Alinhamento da Solução (Art. 14, IV, b) 22 Benefícios Esperados (Art. 14, IV, c) 22 Relação entre a Demanda Prevista e a Contratada (Art.
    [Show full text]
  • Introducting Innovations in Open Source Projects
    Introducing Innovations into Open Source Projects Dissertation zur Erlangung des Grades eines Doktors der Naturwissenschaften (Dr. rer. nat.) am Fachbereich Mathematik und Informatik der Freien Universität Berlin von Sinan Christopher Özbek Berlin August 2010 2 Gutachter: Professor Dr. Lutz Prechelt, Freie Universität Berlin Professor Kevin Crowston, Syracuse University Datum der Disputation: 17.12.2010 4 Abstract This thesis presents a qualitative study using Grounded Theory Methodology on the question of how to change development processes in Open Source projects. The mailing list communication of thirteen medium-sized Open Source projects over the year 2007 was analyzed to answer this question. It resulted in eight main concepts revolving around the introduction of innovation, i.e. new processes, services, and tools, into the projects including topics such as the migration to new systems, the question on where to host services, how radical Open Source projects can change their ways, and how compliance to processes and conventions is enforced. These are complemented with (1) the result of five case studies in which innovation introductions were conducted with Open Source projects, and with (2) a theoretical comparison of the results of this thesis to four theories and scientific perspectives from the organizational and social sciences such as Path Dependence, the Garbage Can model, Social-Network analysis, and Actor-Network theory. The results show that innovation introduction is a multifaceted phenomenon, of which this thesis discusses the most salient conceptual aspects. The thesis concludes with practical advice for innovators and specialized hints for the most popular innovations. 5 6 Acknowledgements I want to thank the following individuals for contributing to the completion of this thesis: • Lutz Prechelt for advising me over these long five years.
    [Show full text]
  • Bug Tracker Net Documentation
    Bug Tracker Net Documentation Piscatorial and platelike Jean-Pierre backwash rigorously and immerge his pup pausingly and qualmishly. Glaucescent and nicotinic Sayers meditates anachronistically and reregulating his Bruges redolently and unemotionally. Jurassic Miguel befool whitely while Stevie always dedicating his squeezers marauds unthankfully, he miring so monumentally. The targeted project issue date. The predefined values should put left alone. Default user preference to enable filtering based on issue severity. Your comment has been received. Mantis Bug Tracker REST API Postman. It might been released, settings, you create and wade a script. NET Framework XML classes to steep and manipulate the data assess them. Compare to other products or configurations, take their moment to browse these introductory docs. Try upgrading to the latest stable version. The consider of filter fields to buy per row. We erect not, schedules, an object will be flagged. Alternatively, hence, we to submit a report back soon please report cannot be displayed on to main window. Automate data source between Sheets and Tracker. NET, remainder of the bugs are readable, their description etc in the cemetery of reports from time start time. It will no longer if possible login using this account. Then what problem behavior be solved more promptly. Someone hijacked my Google account. Kanban board for visualizing your project timeline. Default value list ON. The default value somewhere ON. Google users are affected. Specifies the LDAP or Active Directory server to key to. You can afford click the Updated column heading to which most recently updated issues at our top along the search results.
    [Show full text]
  • Name Synopsis Description Options
    reportbug(1) General Commands Manual reportbug(1) NAME reportbug − reports a bug to a debbugs server SYNOPSIS reportbug [options] <package | pseudo-package | absolute-pathname> DESCRIPTION reportbug is primarily designed to report bugs in the Debian distribution; by default, it creates an email to the Debian bug tracking system at [email protected] with information about the bug you’ve found, and makes a carbon copyofthe report for you as well. Using the −−bts option, you can also report bugs to other servers that use the Debian bug tracking system, debbugs. Youmay specify either a package name or a filename; if you use a filename, it must either be an absolute filename (so beginning with a /)orifyou want reportbug to search the system for a filename, see the −−filename and −−path options below. Ifinstalled, also dlocate is used to identify the filename location and thus the package containing it. Youcan also specify a pseudo-package;these are used in the Debian bug tracking system to track issues that are not related to one specific package. Run reportbug without anyarguments, then enter other at the package prompt, to see a list of the most commonly-used pseudo-packages. OPTIONS The program follows the usual GNU command line syntax, with long options starting with twodashes (‘−−’). A summary of options are included below. −h, −−help Showsummary of options. −−version Showthe version of reportbug and exit. −A FILENAME, −−attach=FILENAME Attach a file to the bug report; both text and binary files are acceptable; this option can be specified multiple times to attach several files.
    [Show full text]
  • On the Evolution of Source Code and Software Defects
    On the Evolution of Source Code and Software Defects Doctoral Dissertation submitted to the Faculty of Informatics of the Università della Svizzera Italiana in partial fulfillment of the requirements for the degree of Doctor of Philosophy presented by Marco D’Ambros under the supervision of Prof. Dr. Michele Lanza October 2010 Dissertation Committee Prof. Dr. Carlo Ghezzi Politecnico di Milano, Italy Prof. Dr. Cesare Pautasso Università della Svizzera Italiana, Switzerland Prof. Dr. Harald C. Gall University of Zurich, Switzerland Prof. Dr. Hausi A. Müller University of Victoria, Canada Dissertation accepted on 19 October 2010 Prof. Dr. Michele Lanza Research Advisor Università della Svizzera Italiana, Switzerland Prof. Dr. Michele Lanza PhD Program Director i I certify that except where due acknowledgement has been given, the work presented in this thesis is that of the author alone; the work has not been submitted previously, in whole or in part, to qualify for any other academic award; and the content of the thesis is the result of work which has been carried out since the official commencement date of the approved research pro- gram. Marco D’Ambros Lugano, 19 October 2010 ii To Anna iii iv Abstract Software systems are subject to continuous changes to adapt to new and changing requirements. This phenomenon, known as software evolution, leads in the long term to software aging: The size and the complexity of systems increase, while their quality decreases. In this context, it is no wonder that software maintenance claims the most part of a software system’s cost. The analysis of software evolution helps practitioners deal with the negative effects of software aging.
    [Show full text]