Analyzing the Context of Bug-Fixing Changes in the OpenStack Cloud Computing Platform

Abstract

Many research areas in software engineering, such as mutation testing, automatic repair, fault localization, and fault injection, rely on empirical knowledge about recurring bug-fixing code changes. Previous studies in this field focus on what has been changed due to bug-fixes, such as in terms of code edit actions. However, such studies did not consider where the bug-fix change was made (i.e., the context of the change), but knowing about the context can potentially narrow the search space for many software engineering techniques (e.g., by focusing mutation only on specific parts of the software). Furthermore, most previous work on bug-fixing changes focused on C and Java projects, but there is little empirical evidence about Python software. Therefore, in this paper we perform a thorough empirical analysis of bug-fixing changes in three OpenStack projects, focusing on both the what and the where of the changes. We observed that all the recurring change patterns are not oblivious with respect to the surrounding code, but tend to occur in specific code contexts.

Changes from the Trenches: Should We Automate Them?

“…They provided valuable information on how developers handle changes of dynamic feature code when fixing bugs. Controneo et al [3] conducted an empirical study on three Python projects and found that the locations of recurring bug-fixing change patterns are specific source code contexts.…”

“…Data edges have additional labels that specify the type of the data flow, like reference, definition, or receiving as a parameter. For example, the fgPDG of the code before in Figure 2 introduces the variable collection and its reference, describes that variables collection and elem are parts of the for 2 PythonChangeMiner: https://zenodo.org/record/4562237 collection [1] collection [2] elem [2] for [2] elem [3] data.add [3] add [3] collection [1] collection [2] data.update [2] update [2] loop condition, and shows that the for loop controls the call of the add method. The two fgPDGs are connected together with map edges that join the corresponding nodes, creating a single united change graph.…”

“…The dataset was compiled in July, 2020, the full list of projects is available. 3 We searched for patterns in the dataset using the same settings as during preliminary experiments: the minimum number of nodes in the graph (the size of the pattern) -4, and the minimum number of samples in the corpus (the frequency of the pattern) -3.…”

“…Software engineering studies encapsulate all steps of the software development life-cycle [29], ranging from requirement analysis [1] to testing [6], deployment [30], and maintenance [14] of the software. Naturally, all of them include changes, which can happen for various reasons, such as refactoring [27], bug fixes [3], implementation of new features, etc.…”

Upgrading Cloud Infrastructure – Challenges and Solutions

“…They did not upgrade the version of Openstack due to the fact that there was not present any clean methodology to do the upgrade without breaking any production services. Because there have been 5 releases since Liberty, the cluster suffers from a lack of features and stability which new features provide [15]. Another problem is that the Liberty release has reached its EOL (end of life) status, meaning that it will not receive any more updates.…”