My journey to figure out LAB 1

Lab 1

     I am starting this lab about a week or two late, but that's because I am unfamiliar with all of the things we are doing. So in an attempt to do this lab, I will document as well what steps I am taking and what I'm thinking as I do so...

     First of all, let's outline the instructions:

Lab 1

1. Select any two open source software packages that have different licenses.
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).
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 how each community's review process works, 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.

     Initially, I have no idea what a license is... so I looked it up on Google.com.

About Open Source Licenses

Open source licenses are licenses that comply with the Open Source Definition — in brief, they allow software to be freely used, modified, and shared. To be approved by the Open Source Initiative (also known as the OSI), a license must go through the Open Source Initiative's license review process.

Popular Licenses

The following OSI-approved licenses are popular, widely used, or have strong communities:

• Apache License 2.0
• BSD 3-Clause "New" or "Revised" license
• BSD 2-Clause "Simplified" or "FreeBSD" license
• GNU General Public License (GPL)
• GNU Library or "Lesser" General Public License (LGPL)
• MIT license
• Mozilla Public License 2.0
• Common Development and Distribution License
• Eclipse Public License

https://opensource.org/licenses

 So therefore, I should be looking for projects with licenses that are similar to the list given, that should be a good indication that I'm in the right place.

I also looked up open source software packages on Google.

https://en.wikipedia.org/wiki/List_of_free_and_open-source_software_packages
https://en.wikipedia.org/wiki/Package_manager

"A package manager or package management system is a collection of software tools that automates the process of installing, upgrading, configuring, and removing computer programs for a computer's operating system in a consistent manner. A package manager deals with packages, distributions of software and data in archive files. Packages contain metadata, such as the software's name, description of its purpose, version number, vendor, checksum, and a list of dependencies necessary for the software to run properly. Upon installation, metadata is stored in a local package database. Package managers typically maintain a database of software dependencies and version information to prevent software mismatches and missing prerequisites. They work closely with software repositories, binary repository managers, and app stores.
Package managers are designed to eliminate the need for manual installs and updates. This can be particularly useful for large enterprises whose operating systems are based on Linux and other Unix-like systems, typically consisting of hundreds or even tens of thousands of distinct software packages." "Software Distribution". Dell KACE. Retrieved 2012-07-11.

 At this point, I still don't understand how packages work... so I will take all this information at face value. It says that its a collection of software tools that will install, upgrade, configure and remove programs... none of which I know how to do myself, so I would not even know what package code does what even if I looked at it at this point. I will have to rely on what the project descriptions say of themselves from here for now.

I will look for some open source software packages now... Inside the list of software packages wiki page, I will go to a section that seems relatively simple to understand (Finance). I'll click on a link that has a simple name (HomeBank). It leads me to another wiki page, but I'm thinking I should be looking for some sort of repository kind of website. On the bottom of the page with External links, there are several sections (Open-source, Freeware, Retail, File Formats and Related topics). These are comparisons of accounting softwares... I'll click web-based inside open source (ummm metafresh option)... another wiki page.. sigh... in external links I see Project Code Repository.. (https://github.com/metasfresh). Finally something that looks like what I need.

Umm... nothing screams packages or license yet... I click the first (post?) on their page that says "

metasfresh

metasfresh ERP Software 

"

I see a whole lot of folders.... oh at the bottom of the list of files I see CONTRIBUTING.md, LICENSE.md... this looks promising!! I go into LICENSE.md, and it shows "

GNU GENERAL PUBLIC LICENSE
                   Version 2, June 1991

" 

at the top... checking the list I had earlier in this post... YES, its my fourth option!! OKAY... so.. umm...

Lab 1 Step 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).  

Okay, it appears to actually be the official GNU document, so I'll read it through (about 3-4 pages) and see if it answers my questions. 

Umm nope.. it basically said everything must be free for everyone to modify and use and that because its free, no warranties exist and anything that is different from the original must be documented and explained clearly to the recipients, etc.. so I guess I'll have to look more at metafresh's github to see if they explain anything rules in detail for THEIR repository. 

Nothing significant in the README.md.. let's try CONTRIBUTING.md.

 Here is what they posted:

How to contribute

• If you don't yet have one, create a github account for yourself.
• Create a fork of the metasfresh repositotory you want to contribute to.
• Make your contribution and create a pull request.
• We will review and comment on the pull request. We may suggest some changes or improvements or alternatives. We will always thread your work and of course also yourself with respect, even in case we choose not to incorporate it into metasfresh.

The process of creating and maintaning a fork with git and github is explained in this article. Note that at the articles end, there is also a link to this article about pull requests.
If you need help, don't hesitate to contact us, for example on our metasfresh gitter chat.
We know that our documentation is still patchy and are keen to improve it!

How to get help

• Here is our current developer's documentation, about how to get the code to compile etc: http://docs.metasfresh.org/pages/developers/index_en
  • Just like with the metasfresh code, we are also grateful for contributions to this documentation
• We have a gitter chat dedicated to this repository. You can enter it at https://gitter.im/metasfresh/metasfresh

 So it appears that they desire contributors to fork (make a copy into their own repos)... then make changes, then make a pull request (which would allow the administrators of the original repository to review and accept their new code - which is merging the pull request).

 Okay, well if that didn't answer the question, I don't know what else the lab is looking for. Now I need to find a second project with a different license.

Back to the original list of open-source packages...
https://en.wikipedia.org/wiki/List_of_free_and_open-source_software_packages

Let's try: Assistive Technology -> Speech (synthesis and recognition)... try Emacspeak...

went to emacspeak.sourceforge.net... lots of 'blah blah blah' but nothing that looks like a repository... try again with something else.

Section -> Networking and Internet -> Web browsers -> Firefox.

The wiki page says the license is: 

	MPL 2.0

  and that is an acceptable license for our blog.. lets figure out what the rules are for contributing...

Their website is all very - "Welcome to Mozilla Firefox!"...  I think this is for users to see.. I'm going to try googling their repo... ("firefox repository")

First link:

https://ftp.mozilla.org/pub/firefox/releases/

makes absolutely no sense to me... oh okay, 4th link seems right (https://github.com/mozilla)

I see a list of (I don't even know what these are.. posts? sections??):

pdf.js
gecko-dev
webdev...

what are these links exactly? sections of mozilla or postings?? anyway, I'll click the first link with pdf.js...

LICENSE says something about Apache License Version 2.0.. which is number 1 in our acceptable licenses. I don't see a CONTRIBUTING.md.. so I'll try README.md.

There's a sub-section that looks like:

Contributing

PDF.js is an open source project and always looking for more contributors. To get involved checkout:

• Issue Reporting Guide
• Code Contribution Guide
• Frequently Asked Questions
• Good Beginner Bugs
• Priorities
• Attend a Public Meeting

For further questions or guidance feel free to stop by #pdfjs on irc.mozilla.org. 

Inside the Code Contribution Guide link:

Contributing code

Below is an overview of how to contribute code to the PDF.js project. The basic workflow is as follows:

1. Fork
2. Create feature branch
3. Make changes
4. Run lint and testing
5. Push changes to your fork/branch
6. Create pull request
7. Code review and automated testing
8. Merge into master

Prerequisites

• Git client
• GitHub account
• Node.js
• Gulp (via npm install -g gulp-cli)

 

So for this project, it also requires forking, but also testing it using lint and other features to do some testing.. same idea with pull requests and merging later on to master by a collaborator.. 

Lab 1 Step 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. 

Now, I'm going to look for an example... within the pdf.js listing I see at the top sub-categories like: Code - Issues - Pull Requests - Projects - Wiki - Pulse - Graphs

I'm gonna click Pull Requests since that seems like the place where people's contributions are waiting to be authorized for merging later on... 

Clicked on:

• Add UMD header to viewer.js
  1-viewer 4-work-in-progress

  #7916 opened 29 days ago by sindilevich • Changes requested

  18  

   

   

   

  Leads me to: https://github.com/mozilla/pdf.js/pull/7916 

   

  The posts seems to go from oldest to newest descending the page. I see there is a section for Conversation, a section for Commits, and a section for Files Changed. It appears to me that in conversations, the contributor is explaining what he is trying to do, and other people can make comments on what he is saying... In commits, I see about 10 different attempts to commit changes, the first several failing the Travis CI build.. but then the newer ones are passing the builds... And in Files Changed, I see that some of the new lines of code in the commits is now being used inside the Files Changed. This must be the master branch then... so this means that those few changes that were used in the commits actually have been accepted into the main project. Cool! So this guy/girl's contribution was meaningful...
  
  So the entirety of the conversations (19 instances) began late December. The contributor is named sindilevich.. the number of reviewers are 2 people, and there is one extra person who was reading and making comments apart from the reviewers. The entirety of the conversations lasted about a week, with the contributor and the reviewers going back and forth almost every day. They were discussing adding a UMD header to viewer.js in order to use it as a real module in environments that support modular resource loading (whatever that means...)

   

  The comment guy asked about fixing linting issues.. sindilevich asked for help because he couldn't get the checks to perform.. they suggested minor changes to his code and gave him some resources to use for an example. He continued to create commits with the changes. The reviewers reminded him to follow contributing rules and make his work up to standard. They also explained to him how their project already implemented certain features, so that the contributor would know which places to look for existing code and what didn't need to be done or altered. They basically showed him how different libraries for .js files worked together and where he could pull code to use without having to start from scratch. The contributor helped where they could and also asked the reviewers to figure out the stuff they knew they weren't equipped to deal with:

  
  

  "@yurydelendik, this PR already resolves items: 1, 2, and 3. But I don't feel myself confident enough in PDF.js codebase to also resolve items 4 and 5. Would be glad for any help, though." 

   

   All in all, they used about 25 extra lines of his code and removed about 5 lines of their own original code. This was all that I could really grasp from the conversations without knowing anything about the actual work they are doing...

   

  Lab 1 Question 4:

   

  Write a blog post discussing your findings. Explain how each community's review process works, 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. 

   

  So essentially, Mozilla's review process consists of contributors holding a conversation about what they are trying to accomplish while making a series of commits. Commentators and reviewers can add comments to the conversation posts, and link to the contributors commits to explain changes that need to be made and remind them about proper processes for contributing. The advantage to this approach is that every step is documented by date and a history of all commits are kept on record for everyone to see the gradual process of changes being made. Also everyone is about to fork the commits and repositories so that any version of the project can be played with at any given time. The other project, metafresh, operated the same way. The disadvantage of such an approach could possibly be that unless there's a way to filter out comments that are not needed, or if there are too many commentators, it might get a little bit messy following what is happening. 

   

  In order to perform a similar patch submission in these communities, I would need to successfully learn how to fork repos, and give access to my commits on the project's commits site inside of a Pull Request section. I think both projects have links that give guides to doing these things so I should follow them and send them a message if I run into problems.

Introduction

Hello,

This is Wayne Williams starting a blog for SPO600. Hopefully some real cool things will be done this semester and we'll get to write about it!! Enjoy!