Open Source Software Write up
1) Linux Kernal. It utilizes the GNU General Public License version (GPLv2).
Patches for Linux Kernal go through a process designed to ensure that each patch is reviewed for quality and that each patch implements a change which is desirable to have in the mainline. The process can happen quickly for minor fixes, or can go on for years for large fixes. Many developers voice frustration at the lack understanding of this process.
2) The process is as follows:
-Design, where the work is done often without involving the community, where the real requirements for the patch and the ways those requirements will be met will be laid out.
-Early Review. Patches are posted to the relevant mailing list, and developers on that list reply with any comments they may have. This problem should turn up any major problems with a patch if all goes well.
-Wide Review. When a patch is getting close to ready for mainline inclusion, it should be accepted by a relevant subsystem maintainer. The patch shows up in the maintainer’s subsystem tree and into the next trees.
-Merging into the mainline. Eventually, a successful patch will be merged into the mainline repository managed by Linus Torvalds. More comments or problems may surface at this time, it is essential that the developer be responsive to these and fix any issues which arise.
-Stable release. The number of users potentially affected by the pathc is now large, so, once again, new problems arise.
-Long-term maintenance. While it is certainly possible for a developer to forget about code after merging it, that sort of behavior tends to leave a poor impression in the development community. Merging code eliminates some of the maintenance burden, in that others will fix problems caused by API changes. But the original developer should continue to take responsibility for the code if it is to remain useful in the longer term.
3) I decided to observe Linux patch 4.14. I was unable to see how long the patch took to go through, but it was a huge patch and have upwards of 50+ people who worked on the patch. Many of the people involved in the patch were resolving issues in the patch, debugging the patch. There seemed to be a lot of problems with the very patch running, they ran into many “frantic” issues as was documented, there were also many x86 errors which imply they encountered issues changing from 32 to 64 as that seemed to be the main purpose of the patch. The Maintainer was a Greg Kroah-Hartman who is a regular maintainer for them., and the patch was released on November 11th 2017.
1) Apache, which utilizes the Apache License
2) Apache requires a specific code style, documentation style, choosing a similar level of Apache code for comparison. Patches for Apache were previously done through mailing list, however this made things very difficult to easily track the patches. Now they accept patches that are submitted through the bug database at: http://issues.apache.org/bugzilla/. You need to create an account on this website, submit the patch by entering a new bug report by explaining how to reproduce the problem and how the patch has been tested. After the bug report has been created, edit it and specify “PatchAvailable” as a keyword and add your patch as a new attachment. However, developers are very conservative about what makes it into the core of Apache.
3) Apache seems to be not very transparent with their patches. I was able to find the lists of their patches, what they do and what they relate to. But regarding the life of the patch in the process, contributors and other information I could not locate. Apache 2.4.29 was the new version of the Apache HTTP server, it at the time was their latest GA release of the new generation of 2.4x branch of Apache HTTPD and represents 15 years of innovation on the project. In introduces numerous enhancements, improvements, and performance boasts over the 2.2 codebase. There were erros with security, event, with proxys, regarding the actual build, the core and log.
My apologies if this entry is a bit long, I ended up getting tunnel vision and writing more than anticipated.