Difference between revisions of "SPO600 Code Review Lab"

From CDOT Wiki
Jump to: navigation, search
Line 10: Line 10:
 
# 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.
 
# 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.
 
# 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.
 
# 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.
# '''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.
+
# '''Write a blog post discussing your findings'''. Explain in detail how each community's review process works (including all of your observations from the previous step with lilnks), 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.
  
  
 
{{Admon/tip|Finding Software Packages|One way to find potential software packages for this lab on an RPM-based Linux system is to take advantage of the rpm database. For example, the command <code>rpm -q -i bash</code> will display information about the ''bash'' package, including the URL of the upstream project as well as the software license.}}
 
{{Admon/tip|Finding Software Packages|One way to find potential software packages for this lab on an RPM-based Linux system is to take advantage of the rpm database. For example, the command <code>rpm -q -i bash</code> will display information about the ''bash'' package, including the URL of the upstream project as well as the software license.}}

Revision as of 11:42, 13 January 2020


Lab icon.png
Purpose of this Lab
This lab is designed to explore the code review processes used in open source projects/communities. This is important to know because you will later be submitting your own code for review.
Note.png
Homework
Unlike other labs, we will not be working on this lab in class -- please complete this lab as homework.

Lab 1

  1. Select any two open source software packages that have different licenses (and therefore are most likely to use different approaches to community organization).
  2. 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.
  3. 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.
  4. Write a blog post discussing your findings. Explain in detail how each community's review process works (including all of your observations from the previous step with lilnks), 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.


Idea.png
Finding Software Packages
One way to find potential software packages for this lab on an RPM-based Linux system is to take advantage of the rpm database. For example, the command rpm -q -i bash will display information about the bash package, including the URL of the upstream project as well as the software license.