SPO600 – Lab 1

The first lab for the course SPO600 is to review two different open source software packages and their review processes. I will be researching the process for the software packages: Ansible and Python.

Ansible – GPLv3
Ansible is a configuration management system for large numbers of computers. Using Ansible scripts and modules you can perform almost any task(shutdown, update, copying files, configurations, etc), across any number of computers, with the single run of a command or even automatically.

Ansible uses Github for their content control system. This shows the source for each release they make, all the commits, the contributors, and the bug tracker they use. Ansible has almost 500 contributors, ranging from over 165,000 lines added(author of ansible) to about 9 lines added. Other communities that are available for Ansible are its mailing list, which is just a google groups forum where uses can ask questions, and the irc channel #ansible on Freenode.

Ansible has a bug tracker on Github, this is used for all bugs that appear, and many seems to be fixed within a day or two. The issue I followed was this one. The poster said what the issue was and why it was happening. One of the contributors then made a patch and closed the bug, with a followup of a test run with the patch which showed the issue resolved. While this particular bug appeared to only have to people involved, there may have been more people behind the scenes since there were possible duplicate issues submitted.

Python – Python Software Foundation License
Python is an interpreted, interactive, object oriented programming language. It is a very popular language which is being used across entire linux systems and even used a lot by users on windows. The python library is very large and there are not too many things that you can’t do in python anymore.

The community page for python shows shows mailing lists, irc, bug tracker, and even some dates or conferences and workshops. The bug tracker uses the Roundup Issue Tracker to control all the issues and tickets. The specific issue I followed was a review of a function for the python subprocess module. This issue had 3 people comment on it and left a link to the actual review of the code. There were a lot of back to back communication about whether this should be put into the subprocces module, along with recommendations and requests to fix bugs. The reviewer was tentative to let this function be added and in the end rejected the patch until it became a little more mature.

The review processes seem fairly similar in function, talk back and forth on a “ticket” or “review request” between usually 2-4 people. Python review process looks to be a lot more difficult than the Ansible process. In the examples I found, Python was rejecting function based on it’s age and whether it had been “very” well tested. Ansible on the other hand seemed to encourage all types of functionality, but seemed picky on how it is envoked in the Ansible scripts, making sure it is universally similar to the rest of Ansible. It really looks like both review processes help the contributor a lot with assistance and information, while trying to keep them on track with different goals/guidelines to get the review approved.


About oatleywillisa

Computer Networking Student
This entry was posted in SBR600 and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s