Reviewing Code and Committing Changes for Open Source Software
Open Source Software Package #1
There were 4 people were involved in the review. There was one person who brought up the issue with steps on how to re-create the issue. Once the issue is posted, a person would review the issue and get more details, if necessary, on how to re-create the issue. After reviewing the issue, it would be assigned to a person, who would create a test case and new branch under a new issue number, if necessary. Finally, there would be a person who reviewed and approved the test case and merge the branch to the master branch.
The process took 238 days, from when the issue was posted to merging the issue branch to the master branch. It took 247 days for the ticket to be closed. When the issue was first presented, it took a month to gain traction. Once it was determined that a test case was required, communication between the person who reviewed the issue and got extra details and the person who was creating the test case became frequent.
The issue was that users were not able to edit keywords if they started typing, clicked General pane then clicked Search pane. This issue occurred in the about:preferences#search in the Firefox browser. They used moziris, which is a tool that manipulates a computer’s keyboard and mouse to test an application and test suites that came from iris Firefox. The steps provided by participants on how the bug occurred were used as the base for the test suites.
To follow the procedure on when the Bug was first introduced to when it was merged and closed, find the Github repository mozilla/iris_firefox and search for issue #3071.
Open Source Software Package #2
There were 4 people involved in the review process. The first person authored the issue and provided in detail the issue that is causing the bug. The second person reviewed the issue the third and fourth person signed-off on the branch and committed the branch to the master branch.
The bug was first brought up on December 18, 2019. The last commit occurred on December 20, 2019. The issue was resolved within two days. Although it does not show the exact date when tasks were completed, such as when it was CC or tested, it does provide a list of who contributed to the branch before commit.
The issue was regarding a memory leak within a function called dasd_eckd_check_characteristics(). Once the program is about to exit the function, the device -> private pointer is set to NULL. After it exits, the resources are not cleaned up due to the NULL status. The issue was resolved by calling another function called dasd_eckd_clear_conf_data().
To follow the procedure on when the Bug was first introduced to when it was merged and closed, find the Github repository here.
The community surrounding Firefox created multiple tickets and used it to keep track of tasks to be completed, which separated reviewing the issue and from testing. For an issue involving an issue where users were not able to edit keywords if they started typing, clicked General pane then clicked Search pane in the about:preferences#search in the Firefox browser, was reviewed by a member of the community. This issue can be found by clicking here. Once it was determined that a test case was required, another ticket was created. Only one branch was created for both the review process and test case. Once the test case code was reviewed and signed-off, it was merged. After this, they communicated to the original ticket that the branch has been merged to master branch and closed. The advantage of this was that it was possible to view each step of the process before the code was committed to the master branch. It was easy to follow, and each contribution was catalogued. A disadvantage of this was the information was scattered across multiple pages. Finding the exact problem and the solution the the issue required reading through the conversation and if more test cases were required, jumping to multiple issue tickets.
The community surrounding Linux used a different approach. The main commit page would include all of the participants and contributions on the front page of the branch number that was committed to the master branch. This gave a clear overview of who was involved, and which participants contributed what to the branch. An advantage of this was how easy it was to find what the problem was and how the issue was resolved. Unlike in the Firefox community, the problem was displayed along with the fix to the issue. A disadvantage was that the details were not clear on who contributed what. Although, it provided who did what, who reviewed or who signed off, it did not include any comments that the contributor may have left. It was hard to single out a specific issue/pull request due to no ticketing number and all commits were grouped into a larger pool of other commits.
I have found that in order to successfully commit to either community, the most important aspect is to communicate. By communicating between participants, the process was reviewed, tested, and merged within a short period of time. Sometimes tests required more information and details come in on a later date, so being active would help resolve the issue quicker.
Follow My Blog
Get new content delivered directly to your inbox.