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

Popular posts from this blog

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 ch...

Final Project Part 02 - Compiler Flags

As mentioned in Part 01 of the project a very noticeable and easy to apply optimization was the -O3 compiler flag as before there was no optimization done at all. This seemed like the -O3 flag was simply forgotten or overlooked, however as I attempted to apply the flag I came across some issues that were disguised by only applying minimal optimization. When I first added the flag to both the STATIC and #else macros in the Makefile I got this issue in the strdup.h file in deps/strdup: fatal error: expected identifier or '(' before '__extension__' After some research and code manipulation I have discovered there are many work arounds to this problem. For one, I could use a different Makefile for the Sha1 function such as in the development version, however this seems impractical and is more like a temporary band-aid solution. Secondly I could alter the strdup function is strdup.h so it does not share the same name as the same function present in string.h which I piece...

Inline Assembler (Lab 7)

Part 1 After given an Inline assembler version of the volume program I made in the last lab, I got some results that shocked me. After running it with the same 500,000,000 sample size It took only 1.2 seconds of computing time, which is better than even the best variant (bit-shifting) of the program I had made by over 50%. I answered some questions below to further my understanding: 1. What is another way of defining variables instead of the (type name register) format? This can be done using normal type variables as the compiler will automatically put values into registers. 2. For the line vol_int = (int16_t) (0.5 * 32767.0); should 32767 or 32768 be used? 32767 should be used because the int will round the value and 32768 is not in the int16_t range. 3. What does __asm__("dup v1.8h,w22"); do? The duplicate simply means copy the int value into a new vector register . This is for SIMD instructions. 4. What happens if we remove : "=r"(in_cursor) ...