uel-london 2010: are developer fixing their own bugs?

8/8/2019 UEL-London 2010: Are Developer Fixing Their Own Bugs?

1/30

IntroductionMotivation

ApproachCase Study and Results

ConclusionsFurther Work

Are Developers fixing their own Bugs?Tracing Bug-fixing and Bug-seeding Committers

Daniel Izquierdo Cortazar

University of East London, London, UK

18th, November, 2010

Daniel Izquierdo Cortazar Are Developers fixing their own Bugs?
http://find/http://goback/


2/30




(cc) 2010 Daniel Izquierdo Cortazar.

Some rights reserved. This document is distributed under the CreativeCommons Attribution-ShareAlike 2.5 licence, available inhttp://creativecommons.org/licenses/by-sa/2.5/

The map of Europe is a derived work. The original one can be found at

http://commons.wikimedia.org/wiki/File:Blank_Map_of_Europe_-w_boundaries.svg

D. Izquierdo Are Developers fixing their own Bugs?
http://commons.wikimedia.org/wiki/File:Blank_Map_of_Europe_-w_boundaries.svghttp://commons.wikimedia.org/wiki/File:Blank_Map_of_Europe_-w_boundaries.svghttp://find/http://goback/


3/30




Table of contents

1 Introduction

2

Motivation

3 Approach

4 Case Study and Results

5 Conclusions

6 Further Work



4/30




Index

1 Introduction

2 Motivation

3 Approach


5 Conclusions

6 Further Work


I d i


5/30




$ whoami


PhD StudentFields of interest:

Libre Software EngineeringLibre Software CommunitiesData Mining

Advisors: Jesus Gonzalez Barahona and Gregorio Robles

Currently a research visitor at UEL


I t d ti


6/30




about GSyC/LibreSoft

Located at Universidad Rey Juan Carlos, Mostoles, MadridYoungest university in Madrid (12 years old)

Escuela Tecnica Superior de Ingeniera de Telecomunicaciones

GSyC (Grupo de Sistemas y Comunicaciones)

http://libresoft.es


Introduction
http://libresoft.es/http://libresoft.es/http://find/http://goback/


7/30




LibreSoft

Academic activities: mining software repositories.Industrial activities (consultant, mobile networking, web 2.0)

Reports related to libre software, like FLOSSImpact.

Master on Free Software (Galicia and Madrid -

http://master.libresoft.es)


Introduction
http://master.libresoft.es/http://master.libresoft.es/http://find/http://goback/


8/30




European Projects

QualOSS: Quality of Open Source Software

FLOSSMetrics: Free/Libre/Open Source Software Metrics

FLOSSWorld: Free/Libre/Open Source Software: Worldwideimpact study

FLOSSInclude: Free/Libre/Open Source Software,International Cooperation

OSOR: The Open Source Observatory and Repository

QualipSO: Trust and Quality in Open Source Systems

Alert: Active support and real-time coordination based onevent processing in open source software development


Introduction


9/30




Index

1 Introduction

2 Motivation

3 Approach


5 Conclusions

6 Further Work


Introduction


10/30




Motivation

Are developers fixing their own bugs?


Introduction


11/30

MotivationApproach

Case Study and ResultsConclusions

Further Work

Scenarios

A

Life of a set of lines

A

previously

participated

A

NOT previously

participated

Fixing a Bug (t)

Previous Change (t-1)



12/30

Introduction


13/30

MotivationApproach


Further Work

Definitions

Source Code Management Repository

CommitterAuthor

Commit

Bug-fixing commit

Bug-seeding commitLine


Introduction


14/30

MotivationApproach


Further Work

Distributed Environment

Changes

ChangesChanges

Central

Repositoy

(Server)

Back round is a derived work fromD. Izquierdo Are Developers fixing their own Bugs?

IntroductionM i i


15/30

MotivationApproach


Further Work

but, how to retrieve data?: Data Sources

Nowadays FLOSS offer a huge set of data mainly based on

next data sources:Source Code Management System: CVS, Subversion, Git,Mercurial, etc.Mailing Lists or ForumsBug Tracking Systems: Bugzilla, GNATs, Trac, Redmine, etc.

Source code: ReleasesOthers.


IntroductionM ti ti


16/30

MotivationApproach


Further Work

Data Mining Approach

Focused just on the Source Code Management system



17/30



18/30

MotivationApproach


Further Work

Diff output

diff -r f1...1d -r 0b...f7 suite/build.mk a/suite/build.mk Fri Jul 25 11:32:27 2008

+++ b/suite/build.mk Fri Jul 25 11:51:57 2008@@ -43,6 +43,10 @@TIERS + = app

+ifdef MOZ COMPOSER+tier app dirs + = editorui+endif+ifdef MOZ CALENDARMOZ EXTENSIONS + = webdav

endif




19/30

MotivationApproach


Further Work

Method

SET OF LINES 1

0 2 4 6 8FILE CURRENTLY AFFECTED

COMMITS AFFECTING LINES

SET OF LINES 2

ADDITION

ADDITION

MODIFICATION

MODIFICATION

SET OF LINES 3

SECTION

STUDIED

CODE

Committer A Committer C




20/30

MotivationApproach


Further Work

Tools

BlameMe is the tool used to retrieve the information

This can be found athttps://projects.libresoft.es/wiki/blameme

This tool stores the information provided for a SCM (Git orMercurial so far) between each pair of revisions.


https://projects.libresoft.es/wiki/blamemehttps://projects.libresoft.es/wiki/blamemehttp://find/http://goback/


21/30



Index

1 Introduction

2 Motivation

3 Approach


5 Conclusions

6 Further Work




22/30



Mozilla Community




23/30



but, why?

They use a distributed SCM: Mercurial (faster to analyze)

Some links with the community what could help to validateresults

Good policy in terms of information found at the commits(bugs are specified)

Research friendly community



A h


24/30



Distribution of Previous Committers

With at most 2 committers around a 80% of the wholesample is being covered

88 264 440 616 792 968 1144 1320 1496 1672

Commits

0

20

40

60

80

100

120

Num.previousCommittersinvolvedatt-1



A h


25/30



Focusing on that 80%

Overall Same Comm. Diff. Comm.

Commits 1,035 62 973

Lines 50,078 973 49,348

Table: One previous committer

Overall S3 (A+B) S4 (B+C)

Commits 357 43 314

Lines 15,581 7,052 (6,834 + 218) 8,529

Table: Commits: two previous committers



Approach


26/30



Index

1 Introduction

2 Motivation

3 Approach


5 Conclusions

6 Further Work



Approach


27/30



Conclusions

Less than a 5% of the bug-fixing commits were handled by thesame committers than those who seeded the bug

Thus, developers are not fixing their own bugs



Approach


28/30



Index

1 Introduction

2 Motivation

3 Approach


5 Conclusions

6 Further Work



Approach


29/30



Open Questions

Even when committers are not fixing their own bugs...

... are they aware than they are introducing errors?We do not still fully understand why a bug was seeded:

Different programming language than used to?Files with loads of changes in a timeframe?Commits submitted in late night hours?

Working on an area where she is not supposed to?



Approach


30/30

ppCase Study and Results


Questions?

Thanks for your attendance!Questions?


[email protected]/LibreSoft - Universidad Rey Juan Carlos


uel-london 2010: are developer fixing their own bugs?

Documents