Supplementary Bug Fixes Vs. Re-opened Bugs
Supplementary Bug Fixes vs. Re-opened BugsLe An, Foutse Khomh, Bram AdamsSWAT–MCIS, Polytechnique Montréal, Québec, Canada{le.an, foutse.khomh, bram.adams}@polymtl.caAbstract—A typical bug fixing cycle involves the reporting ofa bug, the triaging of the report, the production and verificationof a fix, and the closing of the bug. However, previous work hasstudied two phenomena where more than one fix are associatedwith the same bug report. The first one is the case wheredevelopers re-open a previously fixed bug in the bug repository(sometimes even multiple times) to provide a new bug fix thatreplace a previous fix, whereas the second one is the case wheremultiple commits in the version control system contribute to thesame bug report (“supplementary bug fixes”). Even though bothphenomena seem related, they have never been studied together,i.e., are supplementary fixes a subset of re-opened bugs or theother way around? This paper investigates the interplay betweenboth phenomena in five open source software projects: Mozilla,Netbeans, Eclipse JDT Core, Eclipse Platform SWT, and WebKit.We found that re-opened bugs account for between 21.6% and33.8% of all supplementary fixes. However, 33% to 57.5% of reopened bugs had only one commit associated, which means thatthe original bug report was prematurely closed instead of fixedincorrectly. Furthermore, we constructed predictive models forre-opened bugs using historical information about supplementarybug fixes with a precision between 72.2% and 97%, as wellas a recall between 47.7% and 65.3%. Software researchersand practitioners who are mining data repositories can use ourapproach to identify potential failures of their bug fixes and there-opening of bug reports.Index Terms—Supplementary fixes, re-opened bugs, predictionmodel, mining software repositoriesI. I NTRODUCTIONAccording to a report by the US Department of Commerce [11], bug fixing accounts for up to 80% of softwaredevelopment costs. Part of the reason for this is that a typicalbug fixing cycle includes many different phases, performed bya variety of stakeholders: reporting of the bug, production of afix, verification of the fix, and closing of the bug definitively. Insome cases, developers even have to try multiple times beforefixing a bug. As a result of these several attempts, bug reportsare sometimes re-opened, which requires even more time for abug to be fixed and hence is likely to degrade the satisfactionof users and decrease the productivity of development teams,as developers have to rework the same bug multiple times: reanalyzing the context of the bug, reading previous discussionsabout the bug and examining previous failed fixes (proposedfor the bug). Thus, it is important to identify flawed bug fixesearly before they can crash in the field.Work on failed bug fixes has focused on two areas, i.e.,supplementary bug fixes and re-opened bugs. Supplementarybug fixes correspond to multiple commits linked (via theircommit log message) to the same bug report. Park et al. [12]investigated supplementary fixes in three open source projects:Eclipse JDT core, Eclipse SWT, and Mozilla. They concludethat supplementary fixes are typically caused by forgetting toport changes, by incorrect handling of conditional statements,or by incomplete refactorings. On the other hand, the workon re-opened bugs analyzes bug reports that have been closedat least once and re-opened again later, possibly replacing anold bug fix by a newer (possibly more correct) one. Shihabet al. [13], Zimmermann et al. [17], and Xia et al. [15]proposed models for the prediction of such re-opened bugs.Although both areas obviously are related and have spawnedtwo active research communities, their exact relation has neverbeen studied: are re-opened bugs a subset of supplementarybug fixes (or the other way around)?This paper analyzes the relation between supplementarybug fixes and re-opened bugs by studying the factors thatindicate whether a bug fix will require supplementary fixesand–or will be re-opened. Knowing the characteristics of fixesthat require supplementary fixes will help to better focus codereview activities and prevent known bugs from re-appearingin the field. Knowing the characteristics of bugs that requireto be re-opened will help to predict the probability of bugre-opening in order to reduce the maintenance overhead andimprove the overall quality of software. Using bug fix andbug re-opening information from five open source softwareprojects, Mozilla, Netbeans, Eclipse JDT Core, EclipsePlatform SWT and WebKit, we address the following threeresearch questions:RQ1: What is the proportion of bugs among all bug reports that require supplementary bug fixes or are reopened?This research question replicates the work of Park etal. [12], who analyzed Eclipse JDT core, Eclipse SWT,Mozilla and found that between 22.5% to 32.8% ofresolved bugs involved more than one fixing attempt. Inthis research, we want to verify whether supplementaryfixes are related to frequent failure, and hence, whetherthey are worth investigating in details. We find thatthe proportion of bugs that required supplementarybug fixes in Mozilla1 , Netbeans2 , Eclipse JDT Core3 ,Eclipse Platform SWT4 and WebKit5 accounts for,respectively, 23.8%, 17.2%, 26.9%, 25.9% and ipse.org/swt/https://www.webkit.org
of the total number of resolved bugs reports. Only theresults for Webkit are not similar to those of Park etal. We attribute the difference to the style of commitmessages in this project where many commits cannotbe mapped to their corresponding bug reports.RQ2: What is the relation between supplementary bug fixesand re-opened bugs?We want to understand whether bug fix failures arecaught early during reviews and testing activities orwhether they slip through these verification processesand crash in the field, prompting the re-opening of bugreports. According to our result, between 21.6% and33.8% of supplementary fixes have been re-opened atleast once. In addition, bug re-openings tend to coincidewith multiple fixing attempts, long fixing period andmultiple developers. Surprisingly, we also found that,contrary to intuition, 33% to 57.5% of the re-openedbugs were not detected as supplementary fixes, insteadthey are mostly due to premature closing of bugs.RQ3: Can we predict the re-opening of supplementary bugfixes?Re-opened bugs may increase maintenance costs, degrade the overall software quality and the satisfactionof users [13]. In this research question, we use GLM,C5.0, ctree, cforest and randomForest [3] algorithmswith attributes about developers’ working habits, commit logs, bug fix, and development teams’ dynamic, tobuild models that can predict whether or not a bug thatrequired supplementary fixes before initial closing ofits report will be re-opened. Our models can correctlypredict whether or not a supplementary fix will needto be re-opened with a precision between 72.2% and97% and a recall between 47.7% and 65.3%. Softwareorganizations could use our proposed models to predictpotential failures of their bug fixes and the re-openingof bug reports, hence preventing these bugs from reappearing in the field.The rest of this paper is organized as follows. Section IIdescribes the design of our case study. Section III describesand discusses the results of our three research questions.Section IV discusses the results of our replication study inthe context of previous work. Section V discloses the threatsto validity of our study. Section VI summarizes related work.Section VII concludes the paper.A. Data CollectionSince our study replicates existing work on supplementarybug fixes [12] and re-opened bugs [13], we selected thefollowing five open source software projects: Mozilla, Netbeans, Eclipse JDT Core, Eclipse Platform SWT, and WebKit.Mozilla, which was also used by Park et al. [12], is a webproject that includes several sub-products, such as the FirefoxInternet browser and the Thunderbird e-mail client. Eclipse,which was used by both Park et al. and Shihab et al. [13],is an integrated development environment (IDE) supportingvarious programming languages. In addition, to compare withthe results in [12] and [13], we introduced two other projects:Netbeans and WebKit. Similar to Eclipse, Netbeans is anothercommonly used IDE. WebKit is a layout engine softwarecomponent for rendering web pages that powers Apple’s safaribrowser.6B. Data ProcessingFigure 1 shows an overview of our analysis approach. First,we extract bug fix information from version control systems(i.e., Mercurial and Git) and apply the algorithm of Park et al.to identify supplementary bug fixes [12]. Then, we mine thebug repositories (i.e., Bugzilla) of our five subject projects toidentify re-opened bugs. Using these data, we compute severalmetrics and build statistical models to predict the re-openingprobability of supplementary bugs fixes. The remainder of thissection elaborates on each of these steps.1) Identification of bug fixes: We extract the revision history of each subject project from the Mercurial (for Mozillaand Netbeans) and Git (for Eclipse projects, and WebKit)repositories. We obtained the data of the three repositoriesMozilla, Netbeans and Eclipse from the MSR 2011 challenge,which respectively cover the period from March 2007 toAugust 2010, from January 1999 to June 2010, and fromOctober 2001 to June 2010. The WebKit data cover the periodfrom August 2001 to June 2014. Next, we parse the files’revision logs to extract the following commit information:revision numbers, committer names, commit dates, commitmessages, number of changed files, and number of inserted/deleted lines. We apply heuristics from Fischer et al. [6]to identify bug fixing commits. More specifically, we applythe following regular expressions incrementally to match bugreport identifiers:(bug issue)[:#\s ]*[0-9] (b #)[0-9] [0-9] \b\b[0-9] II. S TUDY D ESIGNThis section presents the design of our case study, whichaims to address the following three research questions:RQ1: What is the proportion of bugs among all bug reportsthat require supplementary bug fixes or are re-opened?RQ2: What is the relation between supplementary bug fixesand re-opened bugs?RQ3: Can we predict the re-opening of supplementary bugfixes?Finally, we cross-check the bug IDs obtained from commitlogs with the Bugzilla repository to ensure that they representactual bug reports. i.e., check whether the extracted bug IDsexist in the corresponding Bugzilla repository.2) Identification of supplementary bug fixes: We apply thealgorithm proposed by Park et al. [12] to track supplementary6All our studied data repositories, and analysis scripts are available here:https://github.com/anlepoly/supplementary fixes
Version ControlSystemExtract commitlogsIdentification ofbug fixesCommits withBug IDIdentification ofsupplementarybug fixesRQ1SupplementaryBug FixesAnalyze DataIdentification ofre-opened bugsBug RepositoryRe-opened bugsRQ2RQ2Figure 1: OVERVIEW OF OUR APPROACH TO STUDY THE RELATION BETWEEN SUPPLEMENTARY FIXES AND RE - OPENEDBUGSbug fixes. This algorithm considers as a supplementary bugfix, any fix where the commit message contains the bug ID ofa previous bug fixing commit. Therefore, among all detectedbug fixing commits, we search for revisions where the bug IDis repeated. During this process, we observed that in somecommit messages, committers just mentioned the revisionnumber of a previous bug fix instead of the bug ID. Hence, weenhance Park et al.’s heuristic by also matching these revisionsto the corresponding bugs.Table I presents an example of supplementary bug fixes.In this table, there are three revisions that mention the samebug ID #462381. Revision 21149 is the initial bug fix, whilerevisions 34890 and 34902 are supplementary bug fixes.of a bug, we check the bug’s “history” list and find whetherthere is at lease one “REOPENED” tag. In the case of Mozilla,Netbeans, Eclipse JDT Core and Eclipse Platform SWT, weextract this information directly from the Bug SQL databasesthat were provided for MSR 2011 Mining Challenge. In thecase of WebKit, we concatenate the Bugzilla URL with eachdetected bug ID to download “history” pages of the bug. Then,we check whether the tag “REOPENED” exists in the bug’shistory. For example, to check whether bug #32698 in WebKitwas once re-opened, we combine the history link of WebKitBugzilla and the target bug ID as follows:https://bugs.webkit.org/show bug.cgi?id 32698Table I: S UPPLEMENTARY BUG FIXES OF BUG #462381III. C ASE S TUDY R ESULTSchangeset21149:7aeaf064ad9fdateFri Oct 31 09:07:15 2008 -0700summaryBug 462381 - Build layout directories in parallel r ted sr rocchurn12 files changed, 16 insertions( ), 464 deletions(-). .changeset34890:fae81b8a5648dateFri Nov 13 14:40:00 2009 -0500summarybug 462381 - sprinkle magic PARALLEL DIRS fairy dust aboutthe build system r ted.mielczarekchurn12 files changed, 191 insertions( ), 173 deletions(-). .changeset34902:827d8651799edateMon Nov 16 07:57:15 2009 -0500summarybustage fix from bug 462381churn1 files changed, 4 insertions( ), 2 deletions(-)After the identification of supplementary bug fixes, weorganize all bug fixes into two groups (similarly to [12]):- Type I bug fix - bug fixes that definitively solve the bugin the first attempt (i.e., no supplementary fix is needed)- Type II bug fix - bug fixes that require supplementaryfixes before the bug can be solved.3) Identification of Re-opened Bugs: In Bugzilla, a reopened bug may be marked “REOPENED” in two places: inthe “status” field, when it is currently re-opened and not yetsolved; and in its “history” list, if it was once re-opened butafterwards the status had been changed to something else (e.g.,again “CLOSED”). Instead of just looking at the final statusThis section presents and discusses the results of our threeresearch questions.RQ1: What is the proportion of bugs among all bug reportsthat require supplementary bug fixes or are re-opened?Motivation. This question is preliminary to the other questions. It provides quantitative data on the proportion of bugsthat required supplementary bug fixes and bugs that havebeen re-opened in our five subject systems. In this researchquestion, as in the study of Park et al. [12], we determinewhether bug fixes fail frequently, how fast the bugs are fixedfor good and how many developers are needed for this. Theseresults will clarify the prevalence (and hence importance) ofsupplementary bug fixes, and allow us to compare our findingswith those from [12].Approach. We identify supplementary bug fixes by classifyingbug fixes from the five systems into two categories: Type Ibug fix and Type II bug fix, as discussed in Section II-B2. Weidentify re-opened bugs following the heuristics described inSection II-B3, and compute the proportion of bug reports thathave been re-opened. For each bug report, we also compute thenumber of fixing attempts required for the bug, the duration (indays) of the fixing period, and the number of developers thatcontributed to fix the bug. Since type II bugs contain multiplefixes, we respectively calculate their number of bug fixes andnumber of bug reports (i.e., all fixes corresponding to the samebug ID count for one).Findings. Overall, in the five studied projects, type II bug
Table II: D ESCRIPTIVE STATISTICS OF THE SUBJECT SYSTEMSStudied periodMozillaNetbeansJDT CorePlatform SWTWebKit03/2007 - 08/201001/1999 - 06/201010/2001 - 06/201010/2001 - 06/201008/2001 - 06/2014# commits515001735591809920744152296# detected bug fixing commits41227535997744850449388# Type II bug fixing commits20389 (49.5%)19111 (35.7%)3960 (51.1%)4523 (53.2%)10530 (21.3%)# bug reports# Type I bug reports2734941633517653744332620838 (76.2%)34488 (82.8%)3784 (73.1%)3981 (74.1%)38858 (89.7%)# Type II bug reports6511 (23.8%)7145 (17.2%)1392 (26.9%)1393 (25.9%)4468 (10.3%)# re-opened bug reports2876 (10.5%)5681 (13.6%)707 (13.7%)653 (12.2%)2311(5.3%)Max # of fixing attempts fora bug report9756244536Max # of fixing days for a bugreport1125378116161947889Max # of involved developersfor a bug report6714126attempts - all 2.2%2.8%1.0%0.4%0.2%234561WebKitEclipse Platform SWTEclipse JDT 0.4%0.1%0.1%23456Figure 2: N UMBER OF FIXES REQUIRED FOR BUGS AS WELL AS PERCENTAGE OF BUGS THAT ARE RE - OPENED WITHIN 3FIXING ATTEMPTS AND WITH MORE THAN 3 ATTEMPTSreports account for 10.3% to 26.9% of all the bug reports.Table II shows descriptive statistics about our subject systems.Netbeans has the lowest percentage of commits thatfix a bug. This seems counterintuitive, because Netbeanshas the highest number of commits. However, further manualanalysis shows that more than 20% of commit messages onlymentioned the product repository links instead of bug IDs (e.g.,Automated merge with http://hg.netbeans.org/cnd-main/). Inother words, these commits cannot be identified as fixinga bug. There are also many very short commit messagesfrom which we can not extract any useful information aboutbug fixes with the heuristic introduced in the Section II-B1.This result reveals a limitation of the current identificationalgorithm for supplementary bug fixes.On average, more than one tenth of bug fixes have beenre-opened. Since our re-opened bugs are detected from bothVCS and bug repositories, we can guarantee that any bug fixthat has been re-opened can be identified. The proportion ofre-opened bugs over all detected bug fixes are similar betweenprojects, i.e., from 5.3% to 13.7%.Most bugs required only 1 to 2 fixing attempts and lessthan 24 hours to get fixed. Figure 2 shows the distributionof fixing attempts required for bugs. In the worst case, inMozilla, a bug can require up to 97 attempts before gettingfixed. In other projects, we also found bugs fixed with 24 to56 attempts. To understand the period of time needed to makethe supplementary fixes, Figure 3 presents the distribution offix duration required for bugs. Overall, most bugs are solvedwithin 24 hours (i.e., 1 day). The maximum time taken forfixing bugs is 889 to 3781 days. Some of those outliers (e.g.,bug #3875 in Netbeans) correspond to cases where developersforgot to close a fixed bug report (this is a threat to validity),whereas others (e.g., bug #55701 in Netbeans) really took sucha long time to get fixed.In Mozilla, Netbeans, Eclipse JDT Core and EclipseSWT, the proportion of bugs that required supplementarybug fixes is between 17.2% and 26.9%. This result is similar
days - all d54%86.2%20%0%1.6%1.0%0.8%0.7%23451Eclipse JDT 1.8%3.6%reopenedEclipse Platform %10.7%0.4%0.3%0.2%2345developers- all bugsFigure 3: N UMBER OF FIXING DAYS OF BUGSAS WELL AS PERCENTAGEOF RE - OPENED BUGS THAT ARE FIXED WITHIN 1DAY AND MORE THAN 1 .03%2345111.5%reopenedEclipse JDT %reopened80%80%4.05%Eclipse Platform %0.02%2345Figure 4: N UMBER OF DEVELOPERS PARTICIPATING IN FIXING BUGS AS WELL AS PERCENTAGE OF RE - OPENED BUGS THATARE FIXED BY ONE DEVELOPER AND BY MULTIPLE DEVELOPERSto the finding of Park et al. [12] in which supplementaryfixes account for 22.5% to 32.8% of all detected bug fixes.In Webkit, supplementary fixes account only for 10.3%. Witha manual check, we found that Webkit allows developers touse both SVN and Git clients to access the source code.As a result, many commit messages mention an SVN stylerevision number instead of a Git revision number or a bugID, making it difficult to track all commits related to a bug.For example, the following message could not be mapped toa bug report: “Rebaseline tml after r107389”. The latter number isan SVN style revision number.Overall, in our five studied projects, supplementary bug fixesaccount for 10.3% to 26.9%, while re-opened bugs account for5.3% to 13.7%.RQ2: What is the relation between supplementary bug fixesand re-opened bugs?Motivation. Many factors can explain the supplementary fixesfound in our subject systems. A first explanation could beagile development and continuous integration practices thatadvocate for incremental development, in particular those thatsolved bugs within 24 hours, since developers may have justsubmitted their bug fixes incrementally (i.e., through successive chunks of commits). A second explanation is suggested bythe Type II bugs that experienced multiple bug fixing attemptsover long period of time (up to 3781 days). It is possiblethat long fixing period may increase the probability of bug reopening. A third explanation is that multiple failing attemptsat fixing a bug (many supplementary bug fixes) increases theodds that the bug will be re-opened in the future. A fourth
explanation is that a bug fixing process may involve multiplecommitters. Multiple reasons can explain why different committers would contribute fixes for a same bug, such as theturnover in development teams, or the complexity of a bugthat may require the collaboration of several developers. Toverify these hypotheses, this research question investigates therelation between Type II bug fixes and re-opened bugs.Approach. To verify the above mentioned hypotheses regarding the relation between supplementary bug fixes andre-opened bugs, we split the results in Figure 2 and 3 intwo parts (by dashed lines), to distinguish bugs that requiredless than three fixing attempts, and those that required morethan three fixing attempts (respectively bugs fixed within 24hours, and those that required more than 24 hours). We choosethese thresholds because they correspond to the modes of thedistributions of the number of fixing attempts (respectively thenumber of fixing days). Also, bugs fixed by less than threesuccessive commits, within 24 hours are more likely to belinked to agile development rather than incorrect bug fixes. Ineach figure, we then calculate the percentage of bugs belowand over the above thresholds (on the left and right side ofthe dashed line) that are re-opened. The resulting percentagesshow where re-opened bugs are concentrated the most.Figure 4 shows the distribution of the number of developersinvolved in fixing each bug. Dashed lines separate fixes bysingle developers and multiple developers. For each Type IIbug, we count all different names or emails that appeared inthe same Type II bug fix group (i.e., all the fixing commits of aType II bug) to identify the number of developers involved infixing the bug. Since we extract this information from commitlogs, it is possible that these developers (i.e., the committers)are not the authors of the bug fixes, but are instead reviewerswith commit privileges [2]. A re-opened bug may also beassigned to a different (more experienced) developer in anattempt to avoid further fixing failures. To evaluate this lasthypothesis, we investigate the distribution of re-opened bugsamong the groups of bugs fixed by single versus multipledevelopers.Figure 5 shows the relation between supplementary bugfixes and re-opened bugs. The green circles represent type IIbugs, blue circles represent re-opened bugs, pink circles represent “invalid reports” (i.e., bug reports that have been closedby the following resolutions: “invalid”, “wontfix”, “duplicate”,or “worksforme”, which have a strong probability of beingre-opened [13]). The overlapped parts are their intersection.For example, in Mozilla, there are 6511 type II bug reports(4583 1757 171), from which 1928 are also re-opened bugs(1757 171). Also, 171 of these re-opened bugs were “invalidreports” before being re-opened. We also found 948 re-openedbugs (324 624) with only one commit, among which 324 were“invalid reports” before being re-opened.Findings. Re-opened bugs are more concentrated respectively in the areas above 24 hours, three fixing attempts, orby multiple developers. Overall, between 21.6% and 33.8%of Type II bugs have been re-opened at least once. However,almost half of the re-opened bugs were not detected asType II bug fixes (i.e., we did not find more than onefix for these re-opened bugs). This outcome was quite asurprise for us because we expected re-opened bugs to bea subset of supplementary fixes. At first sight, this findingcould be explained by limitations in our data set, such asdevelopers forgetting to mention a bug ID in their commitmessage. However, closer analysis shows that 22.8% to 49.1%of re-opened bugs with only one fix tend to be linked withinvalid reports, i.e., not all re-opened bugs address previouslyfixed bugs. This seems counterintuitive, but in many cases theoriginal bug fix was prematurely closed because developersconsidered that: the problem described is not a bug (markedinvalid in Bugzilla), the bug do not need to be fixed (marked aswontfix), the problem is a duplicate of an existing bug (markedas duplicate), or all attempts at reproducing this bug werefutile (marked as worksforme). To validate whether the invalidreports are significantly associated with single re-opened bugs,we applied Chi-squared test and Fisher’s exact test to comparethe four types of invalid reports in re-opened bugs with onlyone commit and in those with multiple commits. The resultshows that in all studied systems, the p-value is less than 0.05,i.e., invalid reports have a significant association with singlere-opened bugs. This finding also explains that not all bugre-openings have a negative impact on software development,contrary to the conclusion of earlier works like [13]. In oursubject systems, 22.8% to 49.1% of single re-opened bugs (i.e.,re-opened bugs with only one commit associated) have at leastone of these invalid closed status. Those bugs have less impacton software quality than the re-opened bugs previously closedby the “fixed” status. Therefore, instead of building predictivemodels for bug re-opening over all bug fixes, like in [13], weonly predict bug re-opening for supplementary bug fixes.Therefore, bugs fixed during long period, with multipleattempts or with multiple developers tend to be re-opened.Counterintuitively, almost half of the re-opened bugs have onlyone fixing attempt. 22.8% to 49.1% of these single re-openedbugs are due to prematurely closed reports.RQ3: Can we predict the re-opening of supplementary bugfixes?Motivation. In RQ1 and RQ2, we observed that between10.3% and 26.9% of bugs required at least one supplementaryfix before they were resolved for good. Among these bugs thatrequired supplementary fixes, between 21.6% and 33.8% werere-opened. Bug fix failures, and most of the re-opened bugs arenot desirable since they increase maintenance costs, degradesoftware quality and users’ satisfaction [13]. For example, theaverage time from bug report to bug closing in one of theEclipse projects for re-opened bugs was found to be as muchas twice the average time to resolve a non-reopened bug [13].In this research question, we replicate the work of Shihab etal. [13] to explore statistical models to predict whether or nota bug that required supplementary fixes will be re-opened.Using a prediction model, development teams will be able totarget faulty/incomplete bug fixes for more thorough reviews,preventing re-opened bugs.
MozillaType IINetbeansReopenedType IIInvalid45831757171Eclipse JDT CoreReopenedType IIInvalid324624472919224941537Eclipse Platform SWTReopenedType IIInvalid1728109022181153WebKitReopenedType 20888088Figure 5: R ELATIONSHIP BETWEEN SUPPLEMENTARY BUGS AND RE - OPENED BUGSTable III: W ORK HABIT DIMENSIONTable V: B UG FIX DIMENSIONAttributeExplanation and RationaleAttributeExplanation and RationaleHourHour (0-24). Fix committed at certain hours may induce bugre-opening (e.g., hours around quitting time).Changed filesNumber of changed files in a commit. Large number ofchanged files may increase the risk of bug re-opening.Week dayDay of week (from Mon to Sun). Fix committed on certainweek days may induce bug re-opening (e.g., Friday) [14],[1].ChurnTotal number of inserted and deleted lines. Large number ofchanged LOC may increase the risk of bug re-opening.Fixing timeMonth dayDay in month (1-31). Fix committed on certain days mayinduce bug re-opening (e.g., some dates before holidays).Time span since the first fix. Long fixing time may inducebug re-opening.KeywordsMonthMonth of year (1-12). Fix committed in some monthsmay induce bug re-opening (e.g., December, when we haveChrismas)Some keywords (e.g., crash, error, incorrect) in the commitmessage may imply bug re-opening.Day of year*Day of year (1-366). Combining the rationales of month dayand month.Commit SizeWords in commit message. Too short (due to hasty work)or too long message (due to the difficulty) may lead to bugre-opening.* this attribute was eliminated according to the VIF resultTable IV: B UG REPORT DIMENSIONAttributeExplanation and RationalePlatformPlatform (e.g., PC, Mac) on which the bug was reported.Bugs on some platforms are difficult to be solved, whichmay induce bug re-op
logs with the Bugzilla repository to ensure that they represent actual bug reports. i.e., check whether the extracted bug IDs exist in the corresponding Bugzilla repository. 2) Identification of supplementary bug fixes: We apply the algorithm proposed by Park et al. [12] to track supplementary
an empirical study, due to the following challenges: Challenge 1. It is difficult to collect the bug fixes for the empirical study. First, it needs a large number of bug fixes to ensure the representativeness of the results, but many projects do not provide adequate data for analysis. For example, many
reports using bug tracking software (such as Bugzilla), and then record which change in the SCM system fixes a specific bug in the change tracking system. The progression of a single bug is as follows. A programmer makes a change to a software system, either to add new functionality, restructure the code, or to repair an existing bug.
dumps, etc.) from end-users. These data are sent in the form of bug (crash) reports to the software development teams to uncover the causes of the crash and provide adequate fixes. The reports are . Regular expression for extracting stack traces from bug reports Eclipse.28 Figure 6. Regular expression for extracting stack traces from bug .
168 Ariados Bug / Poison Chelicerata Arachnida Aranae Salticidae, jumping spider 213 Shuckle Bug / Rock n/a n/a n/a possibly an endolithic fungi 347 Anorith Rock / Bug n/a Dinocaridida Radiodonta Anomalocaris 348 Armaldo Rock / Bug n/a Dinocaridida Radiodonta Anomalocaris 451 Skorupi Poison / Bug Chelicerata Arachnida Scorpiones generalized .
Filing a Bug Report - Existing Project File a Bug for an Existing Project - Title for bug! - Summarize - Be Descriptive - Select CSU or Component - Set Severity - Describe Module (file.c), Line of code or function - Attach supporting documents - Set Version ( tag from CMVC ) - Assigned to who? Sam Siewert 8 Be clear on bug .
Updated Information The following table provides update history for the Installation and Configuration guide. Revision Description EN-001649-07 n Revisions for vRealize Automation 6.2.5 including minor updates and bug fixes. n Revised “Specify Server and Account Settings,” on page 48 EN-001649-06 n Installation instructions for vRealize Automation 6.2.4 including minor updates and bug fixes.
The Ultimate Bug Out Bag Checklist 8 The Bug Out Bag List There’s one last order of business before we begin. Here’s a little more context on what we had in mind when putting it together: Ä This bug out bag list is intended for one person. If
influence of ideological values on the policies and practices of America’s criminal justice systems. Recently, however, a trend toward critical analysis of the behavior of police, courts, and corrections has emerged that focuses exclusively on ideology as the analytical tool of choice. For example, Barlow (2000), and Bohm and Haley (2001) include extensive discussion of the influence of .
