Brooks Patola

Contributing to GNU Via Patches

I am doing something that I have yet to learn during my time as a programming student, which is to review how (two) open source software packages handle software changes (“patches”) from their respective communities.

The first open source software package I will be looking into is the GNU project’s Bourne Again Shell (BASH). This shell falls under the GPL-3.0+ license, and for anyone wishing to learn more about the shell, please visit http://www.gnu.org/software/bash/bash.html for deeper learning.

While reading over the website the initial thing that popped out at me was their clear emphasis that if you wish to be a member of the community you should really join the mailing list. This is where members will report bugs and also discuss many other aspects of development. Once you have done this, you will have a few options of how you can help the community as a volunteer. One area is to obviously help with writing code, yet if you are unsure of your ability to perform up to the community standards in this area, they also allow you to help with writing documentation and translation which is pretty neat. Also, depending on the amount of time you have to help, you may play a various role in the community. In order of least time consuming to largest the roles are 1) User (provide feedback to maintainers) 2) Contributor (report/fix bugs) 3) maintainer (project leaders). All development is done using the Git distributed version control system.

I looked at one patch in the community which was for testing/fixing the ISO image installer. Reviewing the patch discussion it can be seen there is the patches original submitter (Christopher Baines), along with another reviewer from the community who had a similar interest in the ISO image, as well as that communities maintainer. There is a clear back and forth between the members to resolve issues in certain areas of the code to perform the tasks the patch seeks to fix. After a responsive discussion that resolved any underlying issues, the patch was pushed and OK’d by the maintainer a little over a week after the initial patch message.  I also learned a new abbreviation in “LGTM”…you can Google that one if you are curious.

Excerpt from discussion (notice “diff” for changes):

Screen Shot 2017-09-29 at 9.08.43 PM

For my second selection, I will be looking into GCC, the system GNU C Compiler. This compiler is under the GPLv3+ license, and if you wish to learn more about this compiler please visit http://gcc.gnu.org.

After looking over the documentation for the first time, it is clear that as with BASH, the GCC compiler will also use a mailing list for patch discussion/submission. Although I do prefer the BASH website documentation for submitting patches as it seemed a tab bit clearer for a new lurker. You are required to install Subversion which is an open source version control system. After this is done you can check out the GCC sources you wish from their SVN source repository and get to work.

Finding a specific lengthy discussion for a patch was difficult to find for GCC as compared to the BASH community. The patch I looked at was labelled “Fix stack-clash protection failures for x86 Solaris”. This mail list discussion only had the original poster who submitted the patch info, which a community member can see has been approved by the “[committed]” tag before the message header. As with BASH we can clearly see the changes the member has implemented into the source code:

Screen Shot 2017-09-29 at 9.08.57 PM

After reviewing both communities it seems that there are no particular disadvantages to note as all members of the community are helping to support one another through mailing list discussions which will either pass as a successful patch contribution or fall away into the forgotten patch abyss. If I was to attempt to contribute a patch myself I believe the most important thing would be to first lurk the discussion lists for enough time to become familiar with the flow and nuances of the community. Along with that it would be extremely wise to become familiar with how each version control system works. Although it seems like a steep learning curve, the comradery and sense of accomplishment a member must feel after contributing a successful patch would be magnificent.

Leave a Comment