scholarly journals Analysing installation scenarios of Debian packages

2020 ◽  
pp. 235-253
Author(s):  
Benedikt Becker ◽  
Nicolas Jeannerod ◽  
Claude Marché ◽  
Yann Régis-Gianas ◽  
Mihaela Sighireanu ◽  
...  
Keyword(s):  
Formal Verification ◽  
Tracking System ◽  
Symbolic Execution ◽  
Large Set ◽  
System Maintenance ◽  
Bug Tracking ◽  
Almost All

Abstract The Debian distribution includes more than 28 thousand maintainer scripts, almost all of them are written in Posix shell. These scripts are executed with root privileges at installation, update, and removal of a package, which make them critical for system maintenance. While Debian policy provides guidance for package maintainers producing the scripts, few tools exist to check the compliance of a script to it. We report on the application of a formal verification approach based on symbolic execution to find violations of some non-trivial properties required by Debian policy in maintainer scripts. We present our methodology and give an overview of our toolchain. We obtained promising results: our toolchain is effective in analysing a large set of Debian maintainer scripts and it pointed out over 150 policy violations that lead to reports (more than half already fixed) on the Debian Bug Tracking system.

From Android Bug Reports to Android Bug Handling Process

2016 ◽  
Vol 7 (4) ◽  
pp. 1-18
Author(s):  
Liguo Yu
Keyword(s):  
Project Management ◽  
Open Source ◽  
Tracking System ◽  
Software Project ◽  
Bug Reports ◽  
Bug Report ◽  
Bug Tracking ◽  
Android Development ◽  
Comprehensive Study

Android is an operating system for mobile devices. Its development is led by Google and some other companies. Because of the open-source property of Android, anyone can report a bug through its online bug tracking system. In this paper, we analyze the bug reports of Android operating systems. Specifically, through this study, we would like to answer the following questions regarding Android development and its project management: (1) Could Android bug reports be handled on time? (2) What is the distribution of different maintenance activities initiated by Android bug reports? (3) How long does it take to handle an Android bug report? (4) Are the number of followers and the number of following messages of an Android bug report related to the effort spent on handling this bug report? Through answering these questions, this paper presents a comprehensive study of Android bug reporting and handling process. The information and knowledge obtained through this case study could help us better understand open-source software project, such as its development process and project management.

The social structure of free and open source software development

First Monday ◽  
2005 ◽  
Author(s):  
Kevin Crowston ◽  
James Howison
Keyword(s):  
Social Structure ◽  
Open Source Software ◽  
Tracking System ◽  
Communication Patterns ◽  
Project Teams ◽  
Development Teams ◽  
The Social ◽  
Wide Range ◽  
Bug Tracking ◽  
The Relationship

Metaphors, such as the Cathedral and Bazaar, used to describe the organization of FLOSS projects typically place them in sharp contrast to proprietary development by emphasizing FLOSS’s distinctive social and communications structures. But what do we really know about the communication patterns of FLOSS projects? How generalizable are the projects that have been studied? Is there consistency across FLOSS projects? Questioning the assumption of distinctiveness is important because practitioner–advocates from within the FLOSS community rely on features of social structure to describe and account for some of the advantages of FLOSS production. To address this question, we examined 120 project teams from SourceForge, representing a wide range of FLOSS project types, for their communications centralization as revealed in the interactions in the bug tracking system. We found that FLOSS development teams vary widely in their communications centralization, from projects completely centered on one developer to projects that are highly decentralized and exhibit a distributed pattern of conversation between developers and active users. We suggest, therefore, that it is wrong to assume that FLOSS projects are distinguished by a particular social structure merely because they are FLOSS. Our findings suggest that FLOSS projects might have to work hard to achieve the expected development advantages which have been assumed to flow from "going open." In addition, the variation in communications structure across projects means that communications centralization is useful for comparisons between FLOSS teams. We found that larger FLOSS teams tend to have more decentralized communication patterns, a finding that suggests interesting avenues for further research examining, for example, the relationship between communications structure and code modularity.

A Method of Statistical Process Control for Successful Open Source Software Projects and Its Application to Determining the Development Period

2016 ◽  
Vol 23 (05) ◽  
pp. 1650018 ◽  
Author(s):  
Shigeru Yamada ◽  
Masakazu Yamaguchi
Keyword(s):  
Process Control ◽  
Open Source ◽  
Statistical Process Control ◽  
Open Source Software ◽  
Execution Time ◽  
Tracking System ◽  
Time Model ◽  
Statistical Process ◽  
Software Release ◽  
Bug Tracking

A software development paradigm for open source software (OSS) project has been rapidly spread in recent years. On the other hand, an effective method of quality management has not been established due to the unique development characteristics such as no testing phase. In this paper, we assume that the number of fault-detections observed on the bug tracking system tends to infinity, and discuss a method of statistical process control (SPC) for OSS projects by applying the logarithmic Poisson execution time model as a software reliability growth model (SRGM) based on a nonhomogeneous Poisson process (NHPP). Then, we propose a control chart method based on the logarithmic Poisson execution time model for judging the statical stability state, and estimating the additional development time for attaining the objective software failure intensity, i.e., the target value of the instantaneous fault-detection rate per unit time. We also discuss an optimal software release problem for determining the optimum time when to stop OSS development and to transfer it to user operation. Further, numerical illustrations for SPC are shown by applying the actual fault-count data observed on the bug tracking system.

scholarly journals Formal Verification Method for Configuration of Integrated Modular Avionics System Using MARTE

2018 ◽  
Vol 2018 ◽  
pp. 1-22 ◽  
Author(s):  
Lisong Wang ◽  
Miaofang Chen ◽  
Jun Hu
Keyword(s):  
Formal Verification ◽  
Schedulability Analysis ◽  
Verification Method ◽  
Prototype Tool ◽  
Spatial Isolation ◽  
Proof Techniques ◽  
Integrated Modular Avionics ◽  
Almost All ◽  
Configuration Information ◽  
Theorem Proof

The configuration information of Integrated Modular Avionics (IMA) system includes almost all details of whole system architecture, which is used to configure the hardware interfaces, operating system, and interactions among applications to make an IMA system work correctly and reliably. It is very important to ensure the correctness and integrity of the configuration in the IMA system design phase. In this paper, we focus on modelling and verification of configuration information of IMA/ARINC653 system based on MARTE (Modelling and Analysis for Real-time and Embedded Systems). Firstly, we define semantic mapping from key concepts of configuration (such as modules, partitions, memory, process, and communications) to components of MARTE element and propose a method for model transformation between XML-formatted configuration information and MARTE models. Then we present a formal verification framework for ARINC653 system configuration based on theorem proof techniques, including construction of corresponding REAL theorems according to the semantics of those key components of configuration information and formal verification of theorems for the properties of IMA, such as time constraints, spatial isolation, and health monitoring. After that, a special issue of schedulability analysis of ARINC653 system is studied. We design a hierarchical scheduling strategy with consideration of characters of the ARINC653 system, and a scheduling analyzer MAST-2 is used to implement hierarchical schedule analysis. Lastly, we design a prototype tool, called Configuration Checker for ARINC653 (CC653), and two case studies show that the methods proposed in this paper are feasible and efficient.

The social structure of free and open source software development (originally published in Volume 10, Number 2, February 2005)

First Monday ◽  
2005 ◽  
Author(s):  
Kevin Crowston ◽  
James Howison
Keyword(s):  
Social Structure ◽  
Open Source Software ◽  
Tracking System ◽  
Communication Patterns ◽  
Project Teams ◽  
Development Teams ◽  
The Social ◽  
Wide Range ◽  
Bug Tracking ◽  
The Relationship

Metaphors, such as the Cathedral and Bazaar, used to describe the organization of FLOSS projects typically place them in sharp contrast to proprietary development by emphasizing FLOSS’s distinctive social and communications structures. But what do we really know about the communication patterns of FLOSS projects? How generalizable are the projects that have been studied? Is there consistency across FLOSS projects? Questioning the assumption of distinctiveness is important because practitioner–advocates from within the FLOSS community rely on features of social structure to describe and account for some of the advantages of FLOSS production. To address this question, we examined 120 project teams from SourceForge, representing a wide range of FLOSS project types, for their communications centralization as revealed in the interactions in the bug tracking system. We found that FLOSS development teams vary widely in their communications centralization, from projects completely centered on one developer to projects that are highly decentralized and exhibit a distributed pattern of conversation between developers and active users. We suggest, therefore, that it is wrong to assume that FLOSS projects are distinguished by a particular social structure merely because they are FLOSS. Our findings suggest that FLOSS projects might have to work hard to achieve the expected development advantages which have been assumed to flow from "going open." In addition, the variation in communications structure across projects means that communications centralization is useful for comparisons between FLOSS teams. We found that larger FLOSS teams tend to have more decentralized communication patterns, a finding that suggests interesting avenues for further research examining, for example, the relationship between communications structure and code modularity.

Sign in / Sign up

Export Citation Format

Share Document