.o PurushothamanPerry05
 Ranjith Purushothaman & Dewayne E Perry 
 Toward Understanding the Rhetoric of Small Source Code Changes
 IEEE Trans Software Engineering  V31n6(Jun 2005)pp510-526 
 =CASE STUDY 5ESS TECHNICAL CODE DELTAS ERRORS 
 40% of changes to code are erroneous(need to be changed after testing).
 The size(LoC) and type(add, delete, modify) of changes seems to effect the chance that they are erroneous.
 10% are one line patches. Only 4% of these are erroneous. 
 (dick)  |- from 2..11 LoC roughly 1% added per LoC.  
 0 errors in deleting up to 10.LoC.
.c

.o Dinh-TrongBieman 05
 Trung T Dinh-Trong & James M Bieman 
 The FreeBSD Project: A Replication Case Study of Open Source Development
 IEEE Trans Software Engineering  V31n6(Jun 2005)pp481-494 
 =POLL OPEN SOURCE PROCESS FreeBSD GNATS 
 Replicates
.See [MockusFieldingHerbsled02??]
 FreeBSD has been developing for 10 years.
 A small group of up to 15 developers controlled the code base.  No more than 50 `top` developers contributed most of the functionality.
 Some ceremony was needed to coordinate work but it is neither imposed nor verified.
 A larger group repairs defects fed by an even larger group of developers who report problems,
 A mechanism for separating stable from unstable code means that stable code will have a lower defect density than commercial feature tested code.
 The developers were users.
.c

.o WilliamsHollingsworth05
 Chadd C Williams & Jeffrey K Hollingsworth 
 Automatic Mining of Source Code Repositories to improve Bug finding techniques
 IEEE Trans Software Engineering  V31n6(Jun 2005)pp466-480 
 =CASE STUDY CODE ANALYSIS TOOL SQA CVS APACHE WINE  
 A tool to spot likely defects can be improved by using historical information on previous fixes.  
 Class of bug: not testing the value returned by a function call to see if it is special or not.
 By selecting unchecked calls to functions with previously fixed defects warns accurately 40% of the time.  Without history the % is much lower.
.c

.o CubranicMurphySingerBooth05
 Davor  Cubranic & Gail C Murphy & Janice Singer & Kellog S Booth 
 Hipikat: A Project memory for Software Development
 IEEE Trans Software Engineering  V31n6(Jun 2005)pp429-526 
 =ADVERT TOOL EVOLUTION DOCUMENTATION WWW EMAIL CVS BUGZILLA 
 Hipikat tool analyzes artifacts gathered in Eclipse development and provides readings to newcomers with maintenance  tasks.
.c

.o ZimmermannWeibgerberDiehlZeller05
 Thomas Zimmermann & Peter Weibgerber & Stephan Diehl & Andreas Zeller 
 Mining Version Histories to Guide Software Changes
 IEEE Trans Software Engineering  V31n6(Jun 2005)pp429-526 
 =EMPIRICAL EVOLUTION OPEN SOURCE TOOL ROSE CVS ECLIPSE GCC GIMP JBOSS JEDIT KOFFICE POSTGRES PYTHON
 ROSE::Eclipse_plugin=http://www.st.cs.uni-sb.de/softevo/
 By analyzing data collected from version histories can predict what else is likely to be changed if one location is changed. Top 3 predictions cover correct predictions 79% of the time.
 Detects undocumented couplings.
 May help prevent incomplete/inconsistent changes.  Few false alarms.
 Fine grain prediction works best on stable systems.  But even unstable systems the files can be predicted,
 Works best in maintenance.
.c