When do changes induce fixes?
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

When do changes induce fixes?

on

  • 2,721 views

Presented at MSR 2005.

Presented at MSR 2005.

Statistics

Views

Total Views
2,721
Views on SlideShare
2,290
Embed Views
431

Actions

Likes
0
Downloads
35
Comments
0

3 Embeds 431

http://forza.cocolog-nifty.com 428
http://app.m-cocolog.jp 2
http://webcache.googleusercontent.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

When do changes induce fixes? Presentation Transcript

  • 1. When Do Changes Induce Fixes? On Fridays. Jacek Śliwerski, Thomas Zimmermann, Andreas Zeller Saarland University
  • 2. The Risk of Change Which changes go wrong? How do we find such “bad” changes? What can we do with them? Idea: combine bug databases + version archives => locate fix-inducing changes
  • 3. The Risk of Change Which changes go wrong? How do we find such “bad” changes? What can we do with them? Idea: combine bug databases + version archives => locate fix-inducing changes
  • 4. Fix-Inducing Changes Fix-Inducing Changes are Changes that lead to problems as indicated by later fixes. Later: Example: ... ... if (foo==null) { if (foo!=null) { foo.bar(); foo.bar(); FIX-INDUCING FIX
  • 5. How to Locate Fix-Inducing Changes
  • 6. How to Locate Fix-Inducing Changes $ cvs annotate -r 1.17 Foo.java ... 19: 1.11 (john 12-Feb-03): public int a() { 20: 1.11 (john 12-Feb-03): return i/0; ... 39: 1.10 (mary 12-Jan-03): public int b() { 40: 1.14 (kate 23-May-03): return 42; ... 59: 1.10 (mary 17-Jan-03): public void c() { 60: 1.16 (mary 10-Jun-03): int i=0; 1.18 Fixed Bug 42233 Changed: a() b() c() line 20 40 60
  • 7. How to Locate Fix-Inducing Changes $ cvs annotate -r 1.17 Foo.java 20: 1.11 (john 12-Feb-03): return i/0; 40: 1.14 (kate 23-May-03): return 42; 60: 1.16 (mary 10-Jun-03): int i=0; 1.11 1.14 1.16 1.18 a() was b() was c() was Fixed Bug changed changed changed 42233 Changed: FIX-INDUCING FIX-INDUCING FIX-INDUCING a() b() c()
  • 8. Bug How to Locate Fix-Inducing Changes $ cvs annotate -r 1.17 Foo.java 20: 1.11 (john 12-Feb-03): return i/0; 40: 1.14 (kate 23-May-03): return 42; 60: 1.16 (mary 10-Jun-03): int i=0; Bug 42233 was reported. closed. 1.11 1.14 1.16 1.18 a() was b() was c() was Fixed Bug changed changed changed 42233 Changed: FIX-INDUCING FIX-INDUCING FIX-INDUCING a() b() c() BUG-INDUCING
  • 9. Bug-Inducing Changes are Indicators for Risk
  • 10. Large Transactions are Risky Average Number of Changed Files Bug- Not Bug- All Inducing Inducing Fix Not a Fix All 3.52 ECLIPSE, for MOZILLA the average is 3.58.
  • 11. Large Transactions are Risky Average Number of Changed Files Bug- Not Bug- All Inducing Inducing Fix 2.73 Not a Fix 3.81 All 3.52 ECLIPSE, for MOZILLA the other way round.
  • 12. Large Transactions are Risky Average Number of Changed Files Bug- Not Bug- All Inducing Inducing Fix 2.73 Not a Fix 3.81 All 7.49 2.61 3.52 ECLIPSE, for MOZILLA the same tendency.
  • 13. Large Transactions are Risky Average Number of Changed Files Bug- Not Bug- All Inducing Inducing Fix 3.82 2.08 2.73 Not a Fix 11.30 2.77 3.81 All 7.49 2.61 3.52 ECLIPSE, for MOZILLA a different distribution.
  • 14. Fridays are Risky, Tuesdays are not ;-) Frequency 11.3% Monday 18.4% 20.9% of all changes 10.4% Tuesday on Tuesday are fixes, 20.9% 11.1% 10.4% induce bugs. Wednesday 20.0% 12.1% Thursday 22.3% 12.2% Friday 24.0% 11.7% Saturday 14.7% 11.6% Sunday 16.9% 0% 5% 10% 15% 20% 25% 30% 35% 40% Fixes ECLIPSE Bug-Inducing Changes
  • 15. Fixes are very Risky Likelihood 8.2% Monday 25.1% that a Change 7.1% Tuesday 22.9% is Bug-Inducing 8.1% Wednesday 23.3% 22.9% of all fixes on 8.8% Thursday Tuesday induce bugs, 23.5% only 7.1% of changes 8.7% Friday 23.2% for new features do. 8.4% Saturday 30.3% 8.6% Sunday 26.4% 0% 5% 10% 15% 20% 25% 30% 35% 40% ECLIPSE Fixes New Features, Refactoring
  • 16. Is MOZILLA broken? Fix transactions are larger than regular transactions (4.39 vs 3.05 files). 48.5% of all revisions are fixes, 41.5% induce later bugs. A fix induces in 45.2% a later bugs, regular changes in “only” 38.1%.
  • 17. For earthquakes and crime rates... Risk depends on Locations The same with risk of changes!
  • 18. resolveClasspath() /* (non-Javadoc) * @see org.eclipse.jdt.launching.IRuntimeClasspathProvider#resolveClasspath * (org.eclipse.jdt.launching.IRuntimeClasspathEntry[], org.eclipse.debug.core.ILaunchConfiguration) */ public IRuntimeClasspathEntry[] resolveClasspath(IRuntimeClasspathEntry[] entries, ILaunchConfiguration configuration) throws CoreException { List all = new ArrayList(entries.length); for (int i = 0; i < entries.length; i++) { switch (entries[i].getType()) { case IRuntimeClasspathEntry.PROJECT: // a project resolves to itself for source lookup (rather than the class file output locations) all.add(entries[i]); break; 9 changes, case IRuntimeClasspathEntry.OTHER: IRuntimeClasspathEntry2 entry = (IRuntimeClasspathEntry2)entries[i]; if (entry.getTypeId().equals(DefaultProjectClasspathEntry.TYPE_ID)) { all of them fixes // add the resolved children of the project IRuntimeClasspathEntry[] children = entry.getRuntimeClasspathEntries(configuration); 8 bug-inducing changes IRuntimeClasspathEntry[] res = JavaRuntime.resolveSourceLookupPath(children, configuration); for (int j = 0; j < res.length; j++) { all.add(res[j]); one re-implementation } } break; default: IRuntimeClasspathEntry[] resolved =JavaRuntime.resolveRuntimeClasspathEntry(entries[i], configuration); for (int j = 0; j < resolved.length; j++) { all.add(resolved[j]); } break; } } return (IRuntimeClasspathEntry[])all.toArray(new IRuntimeClasspathEntry[all.size()]); }
  • 19. Movie with John Wayne (1962) Swahili for “Danger” HATARI Raising Risk Awareness
  • 20. HATARI: Annotations Unrisky Location (green) Risky Location (dark red)
  • 21. Conclusion Fix- and Bug-inducing changes are an measure for (past) risk. We make this risk visible for developers. HATARI will be released in August 2005 http://www.st.cs.uni-sb.de/softevo/ Until then: Don’t program on Fridays! ;-)
  • 22. Sign Gallery