Software Practitioner Views on Merge Conflicts: What is missing?

By: Nicholas Nelson (@nnelson8675), Oregon State University, USA and Shane McKee (@shanemmckee), Intel Corporation, USA

Associate Editor: Sarah Nadi, University of Alberta (@sarahnadi)

We develop software in teams. We write code in separate environments and attempt to integrate our changes, along with everyone else's changes, to form a coherent shared version of the software. Most of the time this process works, most of the time version control systems can easily integrate different versions of the code into one, but approximately 19% of the time there are problems [1][2]. These merge conflicts require human intervention to resolve conflicting changes to the code, and these interventions take time away from regular development.

Prior research efforts have focused on developing smarter merging algorithms [3][4], systems for proactively conflict detection [2][5][6], and discussing the merits of syntax- and semantic-aware merges [7][8]. However, these efforts have not considered the core component of collaborative software development: the practitioners that are writing the conflicting code. As a research community, we need to remember that software engineering involves software practitioners and their perspectives are critical for tuning any proposed solutions to make real-world impact. This fundamental rationale is why we reached out to practitioners; to obtain their perspectives on merge conflicts.

We found that practitioners rely on their own expertise in the conflicting code to understand and assess merge conflicts. Instead of using precise metrics calculated by tools, practitioners tend to rely on their own simple estimations. We additionally found that the complexity of merge conflicts and the size of merge conflicts factor heavily into the assessment of merge conflicts.

Fig 1. Perceptions of merge toolset support along dimensions of conflict complexity and conflict size

To get a better understanding of these two factors, we asked practitioners in the survey to relate their tools along these two dimensions. The combination of four bubble plots in Fig. 1 represents the results of these four scenario questions, and show the number of responses for a given effect level broken out into experience level groups. The size and depth of color within each bubble are also used to convey the size of responses for any given combination.

To better illustrate how to read and interpret these plots, let’s take an example participant with 1-5 years of experience who indicates that her merge toolset is Extremely Effective for small, simple merge conflicts, she would be represented in the bubble containing 15 in quadrant A1. She would also be represented in the bubble containing 9 in the bottom right plot (quadrant A4) if she indicated that her merge toolset was Moderately effective for large, complex merge conflicts.

Mean scores for each A1-A4 plot from Fig. 1 and the difference across dimensions

The greater picture between each of these plots is that the move from plot A1 to A2 (the vertical axis) represents a change only in the dimension of merge conflict size: from small to large. Similarly, the move from A1 to A3 (the horizontal axis) represents a change only in the dimension of merge conflict complexity: from simple to complex. Fig. 2 is an annotated version of Fig. 1 with mean scores for each plot listed in the corners. These scores represent the mean where responses of Extremely Effective is scored as 5 and Not at all is scored as 1. Using numerical analysis, we examined the impact of both dimensions on the mean score and found the shift from small to large merge conflict size (A1 to A2) results in a difference in mean response of 0.496, whereas the shift from simple to complex merge conflict complexity results in a difference in mean response of 0.930. The change in mean score based on a shift in complexity is more than double the mean score based on a shift in size.

These results suggest that merge tools are currently equipped to handle increases in the size of merge conflicts, but not as well equipped for increases in complexity. With the increasing amount of code being developed in distributed environments, researchers and tool developers need to scale their solutions in both dimensions if they are going to continue to be relevant and useful to practitioners.

Further examination and discussions on merge conflicts can be found in our paper:

S. McKee, N. Nelson, A. Sarma, and D. Dig, "Software Practitioner Perspectives on Merge Conflicts and Resolutions," in International Conference on Software Maintenance and Evolution (ICSME), 2017.

References:

[1] B.K. Kasi and A. Sarma, “Cassandra: Proactive conflict minimization through optimized task scheduling,” in International Conference on Software Engineering (ICSE), 2013, pp. 732–741. 

[2] Y. Brun, R. Holmes, M. D. Ernst, and D. Notkin, “Proactive detection of collaboration conflicts,” in International Symposium and European Conference on Foundations of Software Engineering (ESEC/FSE), 2011, pp. 168-178. 

[3] G. Taentzer, C. Ermel, P. Langer, and M. Wimmer, "A fundamental approach to model versioning based on graph modifications: from theory to implementation," in Software & Systems Modeling, 2014, ed. 13(1), pp. 239-272. 

[4] Y.S. Yoon and B.A. Myers "Supporting selective undo in a code editor," in International Conference on Software Engineering (ICSE), 2015, pp. 223-233. 

[5] A. Sarma, “Palantir: Enhancing configuration management systems with workspace awareness to detect and resolve emerging conflicts,” Ph.D. dissertation, University of California, Irvine, 2008. 

[6] M.L. Guimarães and A.R. Silva, “Improving early detection of software merge conflicts,” in International Conference on Software Engineering (ICSE), 2012, pp. 342–352. 

[7] D. Dig, K. Manzoor, R. Johnson, and T.N. Nguyen, “Refactoring-aware configuration management for object-oriented programs,” in International Conference on Software Engineering (ICSE), 2007, pp. 427–436. [8] J. J. Hunt and W. F. Tichy, “Extensible language-aware merging,” in International Conference on Software Maintenance (ICSM), 2002, pp. 511–520.

Participation of Women in Free/Libre/Open Source Software. What is the current status and how much has changed in the last 10 years?

Participation of Women in Free/Libre/Open Source Software. What is the current status and how much has changed in the last 10 years?

by Gregorio Robles, Laura Arjona Reina, Jesús M. González-Barahona and Santiago Dueñas Domı́nguez.
Associate editor: Stefano Zacchiroli (@zacchiro)

It is well known that women are generally underrepresented in the IT sector. However, in FLOSS (free, libre, and open source) projects the number of women reported is even lower (from 2% to 5% according to several surveys, such as FLOSS 2002 [1] or FLOSSPols [2]). The FLOSS community is aware of this situation, and some projects, such as GNOME and Debian, have promoted the attraction of female participants.

As the previous surveys date back from the early 2000s, we designed a new web survey in 2013 which was answered by more than 2,000 FLOSS contributors, of which more than 200 were women. From the analysis of the answers provided by men and women, mainly those ones that are on their involvement with FLOSS, their educational level and background and personal status, we wanted to shed some light on how the status of female participation in FLOSS is. This blog post shows a glimpse of this. The survey responses are publicly available and documented for further analysis by third parties [3].

We have found that women begin to collaborate at a later age than men. Interestingly enough, as can be seen from Figure 1, while both peak at the age of 21, the tail for women is not that abrupt than the one for men. So, women that start in their thirties are 70% of the ones in the 20s, while for men this number decreases to 30%.

Figure 1 - Age of first contribution to FLOSS. Source [4].

Women perform more diverse tasks than men. While the latter are mostly concentrated on coding tasks (only slightly above 20% of men perform other tasks), with almost 45% "other type of contributions" is the main task chosen by women. The percentage of women who mainly code is 31%, as can be seen from Figure 2.

Figure 2 - Type of contributions to FLOSS projects. Source [4]

Figure 3 shows that while a majority of FLOSS participants does not have children, the number of those who have varies largely depending on their gender. So, the number of women with children (19%) is almost half the number of men with children (34%) as shown in Figure 3.

Figure 3 - Answers to the question Do you have children?.

Graphs have different scales. Source [4]

If we have a look at how much time FLOSS contributors devote to FLOSS, we obtain Figure 4. At first sight the distribution might seem very similar, but a closer look shows that the share of men devoting less than 5 hours/week (50%) is lower than for women (54%), as is the the amount of men working 40 or more hours per week (12% for men and 15% for women). So, contributions to FLOSS projects by women are over-represented among the less active and the full-time professional contributors, in the latter case being probably hired by an industrial software company.

Figure 4 - Number of hours per week devoted to contributing to FLOSS projects. 

Graphs have different scales. Source [4]

All in all, our study confirms (and extends) the results from FLOSS [1] and FLOSSPols [2], even if almost 10 years have passed between both. Even if it is possible that the amount of women is now slightly higher, many contextual patterns have remained the same. So, a study of GitHub developers from 2015 found that only around 6% were women [5], but this increase could be due to the major involvement of the software industry in FLOSS. The current situation is far from what ten years ago was set as a goal, so we may speak of a "lost decade" in the inclusion of women in FLOSS.

A pre-print copy of the full paper "Women in Free/Libre/Open Source Software: The situation in the 2010s" [4] can be found at https://flosshub.org/sites/flosshub.org/files/paper-pre.pdf.

References

[1] Rishab A Ghosh, Ruediger Glott, Bernhard Krieger, and Gregorio Robles. Free/libre and open source software: Survey and study, 2002.
[2] Dawn Nafus, James Leach, and Bernhard Krieger. Gender: Integrated report of findings. FLOSSPOLS, Deliverable D, 16, 2006.
[3] Gregorio Robles, Laura Arjona Reina, Alexander Serebrenik, Bogdan Vasilescu, and Jesús M González-Barahona. FLOSS 2013: A survey dataset about free software contributors: Challenges for curating, sharing, and combining. In MSR, pages 396-399, 2014. DOI: https://doi.org/10.1145/2597073.2597129
[4] Gregorio Robles, Laura Arjona Reina, Jesús M. González-Barahona, and Santiago Dueñas Domı́nguez. Women in Free/Libre/Open Source Software: The situation in the 2010s. In OSS 2016, IFIP AICT 472, pp. 163–173, 2016. DOI: https://doi.org/10.1007/978-3-319-39225-7_13
[5] https://www.toptal.com/open-source/is-open-source-open-to-women

The shape of a cryptographic keyring: How is the Debian project social structure like?

By: Gunnar Wolf 
Associate editor: Stefano Zacchiroli (@zacchiro)

Quite often, we can be quite familiar with a set of data; But looking at it with a different viewpoint reveals a completely unexpected reality.

I am part of the keyring-maint group in Debian: The developers that manages the cryptographic keyring through which developers identify themselves for most of our actions — Most important, voting in project decisions and uploading software.

There are two main models for establishing trust via cryptographic signatures: The centralized, hierarchical model based on Certification Authorities (CAs) from where all trust and authority stems and flows only downwards, and a decentralized one, the Web of Trust where each participant in the network can sign other participants' public keys; the first one is most often used in HTTPS (encrypted Web), and our project uses a specific mode of the second one, which we have termed the Curated Web of Trust [1].

Cryptographic signatures are way more secure as identifications to the omnipresent but very weak username/password scheme. However, technological advances must be factored in. Being already 24 years old, Debian is a very long-lived free software project, and it sports a great retention: Many of its developers have been active for over ten years. In the late 1990s, the recommended key size was 1024 bits — Public key cryptography is very expensive computationally, and said key size was perceived secure enough for the foreseeable future. However, according to a study on algorithms and keysizes in 2012, [2] this key size is today good only for Short-term protection against medium organizations, medium-term protection against small organizations — Clearly not below our required standards.

Our group had started pushing for migration to stronger keys back in 2009. By 2014, as the Figure 1 shows, we had achieved the migration of half of the developers to stronger keys; But the pace of migration was really insufficient. At the Debian Developers' Conference that year (DebConf14), we announced that by January 1st, 2015, we would remove all keys shorter than 2048 bits.

Figure 1: Number of keys by length in the Debian Developers keyring, between mid 2008 and late 2015

The migration process was hard and intensive. Given the curated Web of Trust model followed, our policy is that, for a key replacement, a new key must be signed by two currently trusted keys in our keyrings; being Debian a globally distributed project, many people are simply unable to meet other developers. This migration process resulted in us losing close to a fourth of all keys (that is, a fourth of all Debian Developers could no longer perform their work without asking somebody to "sponsor" their actions), we felt it to be quite successful. This migration prompted a deeper analysis into what the keyrings were able to tell about the developers themselves.

Trying to find any emergent properties, we graphed the signatures in the keyring at different points in time. Although most times we got just a useless huge blob, we observed a very odd division starting around 2011; Figure 2 shows the graph close to the point where this split was maximum: January 2012.

Figure 2: Trust relationships in the Debian keyring near the maximum /split/, January 2012

Then, trying to find the meaning of this split, we colored the edges according to their relative age — How long before each of the snapshots was each of the signatures made. This is shown for the above presented keyring in Figure 3.

Figure 3: Trust relationships in the Debian keyring near the maximum /split/, January 2012, graphed by signature age: (Blue: less than one year old; green: one to two years old; yellow: two to three years old; orange: three to four years old; red: over four years old)

Our hypothesis was that the red blob mostly represents an earlier generation of Debian Developers, who have mostly faded from project activity. We presented our findings last May at the 13th International Conference on Open Source Systems [3], together with a first foray into a statistical analysis on key aging and survival.

This rich data set can still yield much more information on the Debian project's social interactions. It's basically just a matter of finding other angles from which to read it!

[1] Wolf, G. E., & Gallegos-García, G. (2016). Strengthening a curated web of trust in a geographically distributed project. Cryptologia, 1-16.
[2] ECRYPT, I. (2012). Yearly Report on Algorithms and Keysizes (2011-2012), Rev. 1.0. ECRYPT II Network of Excellence (NoE), funded within the Information Societies Technology (IST) Programme of the European Commission’s Seventh Framework Programme (FP7).
[3] Wolf, G., & Quiroga, V. G. (2017, May). Progression and Forecast of a Curated Web-of-Trust: A Study on the Debian Project’s Cryptographic Keyring. In IFIP International Conference on Open Source Systems (pp. 117-127). Springer, Cham.