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