The purpose of this lab is to look at how different open source communities handle code patches and the pros and cons of those approaches.
Fluent Bit
The first community I choose to look at is Fluent Bit
Fluent Bit is a Linux log collector and processor. This community uses GitHub for issue tracking and bug fixes. This is a fairly small community and is supported by a company, Treasure data, recently acquired by ARM. Handling pull requests is done by one developer. Every merge is run through a Travis server, and uses DCO signing to track and ensure the software stays open source. A good example of a pull request is this, which is fixing a memory leak. The commit was merged within a few days by the main developer. The request has a well documented layout of the problem and the solution.
This process of having one main developer handling requests works well for a project with a small user and code base. Using a Travis server significantly reduces the time required to test if the request can be merged. This approach is great at making sure that bug fixes and new features are quickly added to the program. However this approach is dependent on the availability of the single developer. This approach would not work in a more active community as it would not be feasible for one developer to handle every request.
In order to submit a request to this community I would need to investigate is what is required to meet the DCO signing requirement. I would also have to read there style guidelines to make sure that the patch would be accepted.
OpenRCT2
The second community I am looking at is OpenRCT2.
This is a open source remake of rollercoaster tycoon 2. I chose this community because it is larger and has more contributors. This community uses a review process to merge patches. To submit a patch it must adhere to the coding style rules. A patch is then reviewed by members of the community. When a patch is merged it is put through two content integration services, Travis and appveyor. Most patches in this community seem to get accepted fairly quickly, with only a few people needed to review the patch. This is a good example of a patch that required some testing and changes. This patch was worked on by three people, the two reviewers both having a large amount of commits with the project.
This process is effective at ensuring that patch integration is simple. The CI systems make this process much simpler and faster than it otherwise would be. However, as patches need review from the community times are slower than on a smaller project, or a project with dedicated developers. However this approach works well for this community as it is a hobby project and not used in any business contexts. Spreading out the work across many developers is needed to maintain an active community, as there are no businesses driving development on the project.
In order to submit a patch to this project I would need to familiarize myself with the coding guidelines. I would also need to set up there build environment across multiple platforms in order to make sure any patched I make would be platform independent.