Lab 01: Code Review

Select any two open source software packages that have different licenses (and therefore are most likely to use different approaches to community organization).

ReactJs is a open source JavaScript library for building user interface usually in (but not limited to) web developments.
source: https://reactjs.org/tutorial/tutorial.html#what-is-react

PostgreSQL is a open source object-relational database system usually for (but not limited to) managing data warehouse and Web services.
source: https://www.postgresql.org/

Research the procedure used by those projects to accept code ("patches") from contributors. This may be through a mailing list, bug tracker, or source code management system (SCMS)/version control system (VCS) such as Mercurial, Bazaar, or Git/GitHub.

ReactJs: All works/contributions can be submitted through software development version control, GitHub. Which is licensed by MIT Licensing.

PostgreSQL: PostgreSQL is Licensed under PostgreSQL License, yes they have their own License. Thus all their works/contributions are submitted through their own website.
source: https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F

Identify one software change ("patch") successfully submitted in each community, and observe the entire review process from start to finish. Note how many people were involved in the review, the role of those people in the community and project, how long the whole review took, how responsive the participants were to updates in the process, what kinds of issues were discussed, and how issues were resolved.

ReactJs: v16.12.0
Release Date: Nov 13, 2019
Number of contributors: 25+

Most of the contributors are from the react core team, while many others are frequent contributors. I believe development and reviews are done simultaneously through out patch development, as of today they are still reviewing the changes.
Ever since release, the average commits are around 5-6 per day. There are only 5 comments recorded on GitHub, so I believe the core members would have a different communication platform for discussion.
From recorded comments on GitHub, some of the issue discussed are coding and error debugging. And it was no  indication of resolved.

PostgreSQL: PostgreSQL 12
Release Date: Oct 03, 2019
Number of contributors: 410+

From their Acknowledgments, there are at least 410 contributors which includes; patch authors, committers, reviewers, testers, and reporters of issues. All reviews for PostgreSQL developments are done through their Commitfest website (https://commitfest.postgresql.org/), and the reviews for patch 12 can be seen everywhere before and after the release month.
The reviews can cover a wide range of issues like bug fix, documentation errors, monitoring & control, and more...

Write a blog post discussing your findings. Explain in detail how each community's review process works (including alll of your observations from the previous step), the reasons for what you've observed, and note the advantages and disadvantages of each approach. Consider what you personally would have to do and learn in order to successfully submit a patch to each community. Include links to the particular patch/issue that you observed.

Reactjs
Reactjs uses GitHub for their open-source software development. Anyone can signup and follow their contribution guide to post and submit a change through GitHub.
From their Reactjs website and GitHub, many guides and tutorials exist to cover the many steps to download their latest complete version for anyone to work on.
All changes would be submitted to the master branch of the latest stable version as pull requests, then the core team would monitor the request and either apply them or close them with an explanation.

This method of patching would be very organized but with the disadvantage of time consuming. Also if someone would submit a pull request after a new stable version release, then their work would be useless.

PostgreSQL
PostgreSQL uses their own website, Commitfest to review patch submissions. Anyone can signup to Commitfest and free to submit and review patches for old and new versions of the software. All submissions are categorized by a range of date, and there would be an indication of which version the patch is directed to.

This method of patching would sometimes keep the contributor in the dark of whether their work was useful, so there would be no discouragement to the contributors. And whenever the patch is later for the party, they would just move them to the next Commitfest. This also mean the patches would seen as very disorganized to the contributors, but would take less time for the core team because they can just discard unnecessary patches.









Comments

Popular posts from this blog

Course Project Stage 2 Introduction

Course Project Stage 2 part 2: Profiling