Are developers fixing their own bugs?: Tracing bug-fixing and bug-seeding committers

This is the post-print version of the Article. The official published version can be accessed from the link below - Copyright @ 2011 IGI GlobalThe process of fixing software bugs plays a key role in the maintenance activities of a software project. Ideally, code ownership and responsibility should be enforced among developers working on the same artifacts, so that those introducing buggy code could also contribute to its fix. However, especially in FLOSS projects, this mechanism is not clearly understood: in particular, it is not known whether those contributors fixing a bug are the same introducing and seeding it in the first place. This paper analyzes the comm-central FLOSS project, which hosts part of the Thunderbird, SeaMonkey, Lightning extensions and Sunbird projects from the Mozilla community. The analysis is focused at the level of lines of code and it uses the information stored in the source code management system. The results of this study show that in 80% of the cases, the bug-fixing activity involves source code modified by at most two developers. It also emerges that the developers fixing the bug are only responsible for 3.5% of the previous modifications to the lines affected; this implies that the other developers making changes to those lines could have made that fix. In most of the cases the bug fixing process in comm-central is not carried out by the same developers than those who seeded the buggy code.This work has been partially funded by the European Commission, under the ALERT project (ICT-258098)

Do the Fix Ingredients Already Exist? An Empirical Inquiry into the Redundancy Assumptions of Program Repair Approaches

Much initial research on automatic program repair has focused on experimental results to probe their potential to find patches and reduce development effort. Relatively less effort has been put into understanding the hows and whys of such approaches. For example, a critical assumption of the GenProg technique is that certain bugs can be fixed by copying and re-arranging existing code. In other words, GenProg assumes that the fix ingredients already exist elsewhere in the code. In this paper, we formalize these assumptions around the concept of ''temporal redundancy''. A temporally redundant commit is only composed of what has already existed in previous commits. Our experiments show that a large proportion of commits that add existing code are temporally redundant. This validates the fundamental redundancy assumption of GenProg.Comment: ICSE - 36th IEEE International Conference on Software Engineering (2014

Usability discussions in open source development

The public nature of discussion in open source projects provides a valuable resource for understanding the mechanisms of open source software development. In this paper we explore how open source projects address issues of usability. We examine bug reports of several projects to characterise how developers address and resolve issues concerning user interfaces and interaction design. We discuss how bug reporting and discussion systems can be improved to better support bug reporters and open source developers

Exploring usability discussions in open source development

The public nature of discussion in open source projects provides a valuable resource for understanding the mechanisms of open source software development. In this paper we explore how open source projects address issues of usability. We examine bug reports of several projects to characterise how developers address and resolve issues concerning user interfaces and interaction design. We discuss how bug reporting and discussion systems can be improved to better support bug reporters and open source developers