Lab 1

In this lab I will be reviewing two open source communities and the process of submitting and reviewing patches.

The first community I investigated was the android source code https://source.android.com/index.html. To contribute to this community you have to have git and repo. Repo is a repository management tool they have built on top of git. To upload your patches/changes you need to establish a password with their server as well.  After pulling a branch and making changes you have to start a repo in that directory, add the repo to git and then commit. They request a short description as well as a longer description (with specified guidelines) of the changes in the commit message. You then upload your repo and wait for approval. Approval for your patch comes from reviewers who are assigned to the project. Reviewers then have a check list to complete to verify a patch. To become a reviewer you must contribute high quality code to at least one project. The advantage to this system is that reviewers have proven themselves to have a general understanding of the project. The disadvantage to this is finding reviewers resulting in a much slower process. The android open source community allows for code-review and build-review online for the community to review, test and offer help to pending patches. It also tells you the stage of review the patch is in for ex Code-Review, Presubmit-ready, Presubmit-verified or verified.

The second community I looked at was Fedora. To join fedoras release engineers https://docs.pagure.org/releng/ you have to first get involved in some of the IRC meetings. They grant access little by little due to the sensitive access required for release engineering. After submitting a few bugs, little access will be granted for pushing updates and more will be granted as you submit more releases. Patches and bug fixes are reviewed and tested by the community publicly with an up vote and down vote system. The advantage to this approach is a wider set of eyes will be reviewing changes allowing for cheaper and faster reviewing. The downside is that not every one voting will have expertise on the subject, ultimately the head release engineers will have final say on all patches. Patch details are usually discussed over IRC between other release engineers as well as discussed and tested on community forums.