Skip to main content

Comparing Open Source Software Packages (Lab 1)

This post examines code review processes to understand how and where to look to push code upstream


OpenLDAP

This software is best described on the application's project overview page as a "robust, commercial-grade, fully featured, and open source LDAP suite of applications and development tools". (
https://www.openldap.org/project/ )

 This software operates under it's own OpenLDAP public license and accepts patches through the OpenLDAP Issue Tracking System. Patches are approved by the OpenLDAP Core Team, most noticeably Howard Chu and Kurt Zeilenga. An example of a closed patch is Contribution# 5410 where a developer Peter O'Gorman added a patch to allow building of a module with a different compiler addressed to Howard Chu (Chief Architect). The issue was concluded over nine days after two replies to the original message.  Change was implemented and the developer was very prompt (three hours after Architect reply) to respond.

The Issue Tracker OpenLDAP employs allows all changes to be monitored by senior developers and ensures quality control. However, as patches must be hosted through a URL to the source file it makes for more difficult version control. As well, although the issue will appar closed with notes adressing the change to be pushed, it does not directly link one of the core team as pushing the change.

To effectively contribute to this software I would have to read the documentation, build and study the software, analyze software bugs, and sign the notice of origin for ten new lines of code or more as well as having all code available in a git patch for easy implementation.

Curl

This is an "open source software" that is "used in command lines or scripts to transfer data"(https://curl.haxx.se/).

This software is published under a MIT/X derivative license and accepts patches through both git pull requests on their repository (preferred) and the curl library mailing list (https://curl.haxx.se/dev/contribute.html). Patches are approved mainly by Daniel Stenburg the founder of Curl while other trusted and continuous developers also commit and approve code changes and additions. An example of a closed patch is pull request #1871 which was to fix HTTPS proxy support. This was completed by the developers Johannes Schindelin and Jay Satiro addressed to the attention of Daniel Stenburg. The issue was adressed in the span of two days where both parties were very quick (same day) to respond. The change was approved and comitted by Daniel Stenburg.

GitHub is the main source for all code Curl uses. The code not completed by trusted developers is mainly approved by Daniel Stenburg the owner who is the most dedicated to the project. This ensures only the best code is used for development, however this puts a lot of strain on one person and may leave room for error. GitHub has fantastic version control alongside a great commit system, issue tracking, and pull requests. 

To contribute to this software I would need to first read the "Source code, the man pages, the INTERNALS document, TODO, KNOWN_BUGS and the most recent changes in git" (https://curl.haxx.se/dev/contribute.html). Second to this I would have to make a patch against the master branch documented as a pull request on the Curl repository that matches the coding style and is considered a quality patch. If this meets the test case and is approved by Daniel the patch would be accepted upstream.


Comments

Post a Comment

Popular posts from this blog

Final Project Part 01 - Final Summary

To end part 1 I will summarize what information I have gathered for part 2: I am optimizing clib, a package manager. After benchmarking, it is clear there is a significant time delay in some advanced calls of the SHA1 function, such as ones that call update many times. To optimize, I am going to add the -O3 flag and remove a loop condition (currently). Some other observations: This project is relatively small with no ./configure for other platforms. The Sha1 code is unique and does not conform to the simple sha1 algorithm such as on    Wikipedia . The documentation (i.e. README) is relatively vague at describing the dependancies. It suggests only syntax that implies installation and isn't clear at documenting development vs. published code.   I have learned alot getting to this point in part 1. Firstly, I learned that library files can only be linked by using sudo ldconfig and the files must be in usr/lib. Secondly, I learned how to alter an advanced Makefile's fla
Post a Comment
Read more

Final Project Part 02 - Sha1 Function Enhancements

To try to squeeze out a bit more performance I attempted to some compiler optimizations. Unfortunately, due to the sheer complexity of the algorithm, I was unable to find other logic complexities to simplify. I tried some loop unrolling to make the compiler have to work a little less, some examples are here below: I made a graph to demonstrate the minute differences this makes in the test vectors below: At most a few millisecond difference is all that can be acquired, and this is only from the finalcount[] array as the digest array produces errors if not compiled in a loop along with other for loops in the code. To test this I simply altered the sha1.c code and ran the make file to see if the vectors passed or failed. As mentioned this is a compiler optimzation, in other words it is completed already, especially at the -O3 level where the benchmarking was done. I would not  recommend this change to be pushed upstream normally due to the insignificant time change
Post a Comment
Read more

Final Project Part 02 - Final Summary

In conclusion, the -O3 flag was the most important discovery with trying to optimize clib. It offered a significant speed up with no interference, and provided the chance to uniform a many times used function, strdup. Overall the function is built extremely well with very advanced logic. Attempting to alter said logic sprouted many errors and warnings and left only simple compiler optimizations such as loop unrolling which made small differences in speed up. Clib as a whole is a great idea, offering many compartmentalized features for the C programming language that programmers could definitely find useful when developing. I hope in the future I can get more involved in writing code for open source projects such as clib whether that be doing optimization work or building from the ground up. This project not only gave me an insight on how these open source projects work but also at real world coding and improvement opportunities. I can honestly say now that I have had some experience
Post a Comment
Read more