论文笔记——An Empirical Study of Supplementary Bug Fixes
An Empirical Study of Supplementary Bug Fixes
这篇文章关于patch的不完整所做的一个study，整理出来了认为对自己比较关键的地方，以供以后参考。
文章思路：
abstract、introduction、介绍相关工作、描述study 目标和分析方法、呈现empirical（经验的）结果、讨论有效性的威胁、总结study。
abstract
1、omission的errors比commission的对于开发人员来说更难detect到
2、There have been very few studies on why errors of omission occur in practice and how such errors could be prevented.
现在有很少的工作针对为什么会出现遗漏的错误和这些错误如何被阻止。
3、本文针对三个软件（Eclipse JDT core, Eclipse SWT, and Mozilla）的研究表明已经修复的漏洞存在着大量的（a significant portion of，22%-33%）有着多次的修复。
4、手工分析(manual inspection) 表明出现遗漏的错误的原因是多种多样的：
missed porting changes, incorrect handling of conditional statements,
or incomplete refactorings（错过了移植更改，错误处理条件语句，
或不完整的重构）。
5、列出来发现了什么：比如二次补丁和初始补丁一般距离很远，或者没有直接依赖关系，比如调用，访问什么的。
introduction
1、先介绍了之前的工作如何降低或者阻止遗漏的错误的发生，引用了很多篇文章，比如：
（1）code clones of an existing bug fix to reduce potential missed updates
（2）use the dependency structure of a change set to suggest where additional changes need to be made
（3）predict additional change locations based on historical co-change patterns derived from version histories
（4）predict additional change locations based on cochange patterns and the dependency-graph of a change set in conjunction
作者自己说之前的工作都在大量的假设建议额外改变位置，但是没有工作来研究在实际中多久和为什么会有不完整的patch出现。
2、所以作者的工作：
调查和总结现有后续补丁的特征——来应用到附加修补或者纠正现有patch，调研需要后续补丁的漏洞的百分比，他们的严重水平，和初始patch的关系，位置，历史版本号等。
/3、contribution：先提出问题然后得出结论。
（1）多少个bugs需要后续patch？
用调研的三个软件的百分比说明了，没有说具体数目。
（2）不完整的补丁的共同原因？
随机取100个有后续补丁的例子，检查他们的内容和相对应的初始patch。手工分析得出来结论，多种多样的：“missed porting changes, incorrect handling of conditional statements, and incomplete refactorings”，发现不完整的patch的大小和文件的数量大于规律的patch，而且更加零散。
（3）后续补丁和初始补丁相似么？
用了CCFinder，比较后续补丁和初始补丁，发现只有很少的代码相同。
（4）后续补丁相比初始补丁在哪个位置？
一部分有直接关系，比如调用，访问，剩下的没有直接的依赖关系或者没有重合。
related work
Errors of Omission
之前的工作如何分析遗漏的错误
Empirical Studies of the Extent of Supplementary Bug Fixes
发现最难的bug的类型是concurrency的，多次给补丁打patch占据一个可观的数目，
Change Recommendation Systems for Supplementary Fixes
study approach
介绍一下研究的三个软件（Eclipse JDT core, Eclipse SWT and Mozilla）的特点，用什么语言写的，作用，包括的产品。
研究的年份，介绍了之前的研究发现了什么，怎么进行研究的方法，流程，具体的操作步骤，用什么工具进行的步骤，拿出一个例子解释流程。
给bugs分成两类，只打过一次patch和打过多次patch的。
results
分四个部分，介绍多次patch的bug数目和严重性；通过100个不完整的patch手工分析出来的成因；用代码克隆检测分析是否后续patch和初次patch有关联的地方；调查后续patch和初次patch的位置关系。
How Many Bugs Require Supplementary Patches?
用表展现，具体bug的数目，对应patch的次数…
得出结论：相当一部分的bugs需要多次patch，需要更多的开发者去解决这些问题。
What Are The Common Causes of Incomplete Bug Fixes?
为了更好地理解为什么遗漏的errors会在实际中出现，对incomplete patch和regular patch抽象出来了特征，随机选择了100个incomplete patches，inspected their patch contents, the structural dependence relations between an incomplete patch and its supplementary patches, and the associated bug reports。下面是发现：针对每个发现举出来了一个例子对应：
- An initial patch is ported to a different component or branch.
- The conditional statement of an initial fix is not correct.
- Code elements referring to or being referenced by changed code (i.e., calls, accesses, or extends) are later updated
- An initial patch is reverted
- Two different parts calling different subclasses of the same type are not updated together
- Incomplete refactoring induces a supplementary patch.
- The locations of incomplete and supplementary fixes are related but cannot be checked using the Java compiler.
- An initial patch is refactored during supplementary fixes.
- The comment is improved to explain an initial patch in detail.
- Others.
然后得到结论：“The common causes of incomplete fixes are diverse. Incomplete patches are larger in size and more scattered than regular patches.”
Are Supplementary Bug Fixes Similar to Corresponding Initial Fixes?
调查不一致的克隆管理引起补充错误修复的频率，measure the content similarity
between a supplementary patch and its initial patch。用svndiff和CCFinder工具来跟踪patches和识别最初patch和后续patch的cloning relationship。
得出结论：Predicting a supplementary fix location using code clone analysis alone is insufficient.
Where Is The Location of Supplementary Bug Fixes in Relation to Initial Fixes?
结论;About 15% of supplementary change locations are beyond the scope of the direct neighbors of initial patch locations.
Discussion
Identification of Cloned Patches
在本文的研究中，a supplementary fix revision is regarded as a cloned patch when it has similar code chunk from an initial patch, longer than five lines. However, it is possible that only few lines of a supplementary patch is similar to the initial patch.
Relationships among Supplementary Patches
The Studied Period of Bug Reports
New Tools for Reducing Incomplete Bug Fixes.
本文工作表明，相当数量的不完整的patch由于不能覆盖所有情况的patch导致的，表示changed block的control flows的不同的工具可以缓解这种情况。
Conclusions
为了调查为什么会出现遗漏的错误和这些错误怎么样能够被阻止，我们调研了不完整patch和后续patch的特征。
Incomplete patches tend to be larger and more scattered than regular patches。
出现遗漏的errors的原因是多种多样的：
including missed porting changes, incorrect handling of conditional statements, or incomplete refactorings。