DPS909 & OSD600 Fall 2017

From CDOT Wiki
Revision as of 11:09, 11 October 2017 by David.humphrey (talk | contribs)
Jump to: navigation, search

Resources for DPS909 & OSD600

Week 1

  • Some questions:
    • What brought you to this course?
    • When you hear "open source," what comes to mind?
    • On a scale from 1 (not at all) to 5 (very)...
      • How comfortable are you working with technology you've never seen before?
      • How likely are you to stick with a problem when it gets hard to solve?
      • How curious are you about how things work?
      • How likely are you to ask for help when you get stuck?
      • How likely are you to pause your own work in order to help someone else who is stuck?
      • How comfortable are you as a writer?
      • How self-motivated are you?
      • How self-directed are you?
  • How to have Success in this course:
    • Willingness to be lost and not panic
    • Willingness to put yourself out there, jump in
    • Curiosity
    • Being driven, persistence
    • Willingness to ask for help
    • Willingness to give others help
    • Independent learning
    • Doing more than the bare minimum
  • Mozilla
    • Browsers (Firefox, Servo)
    • Languages (JavaScript, C++, Node, Python, Rust, CSS, HTML, ...)
    • Tools (Dev Tools, DXR, build systems, automation)
    • QA, Automated Tests
    • Extensions
    • Localization
    • Documentation
    • Accessibility
    • Teaching and Learning (Thimble)
    • Web technology

Week 2

  • Let's talk about Copyright and Open Source Licenses
      • IANAL: "I Am Not A Lawyer"
      • We're going to explore licensing from the POV of a developer participating in open projects
  • Copyright
    • Who created it, "owns" it.
    • Set of exclusive rights granted to the work's creator
    • "The right to copy," to produce or reproduce a work or substantial portion thereof
    • Copyright is automatic when a work is created, you don't have to register it.
    • Copyright in Canada
    • Copyright Guide
    • In a software project, there can be many copyright holders (e.g., many contributors), or all contributors may assign their copyright to the project (e.g., CLA, which we'll cover later)
  • Licenses
    • Rights, privileges, responsibilities, etc. applicable to someone other than the work's creator
    • "Terms and Conditions"
    • These must be granted by a copyright holder

Week 3

  • What is a bug?
    • Unit of Work in Open Source
    • Many projects have lots of bugs
    • Steps To Reproduce (STR)
    • Metadata (OS, versions, other context)
    • Issue vs. Pull Request
    • Labels

Week 4

Week 5

  • Register for FSOSS 2017 at table outside CS office at lunch time. $25 per student, includes lunch + swag.
  • Learning Licenses: GPL
    • Free Software, FSF, GNU
    • Copyleft, compare to permissive licenses like BSD, MIT
      • "Copyleft thus uses copyright law to accomplish the opposite of its usual purpose: instead of imposing restrictions, it grants rights to other people, in a way that ensures the rights cannot subsequently be taken away." Wikipedia
    • GPL License
    • Key Ideas
      • Free to use, modify (see below), redistribute, study, copy
      • Binary distributions must also make source code available (e.g., Linksys, BMW)
      • You can modify GPL code and not publish your changes. But if you release your modified binary, you must make source available.
      • You can sell GPL licensed code, and so can anyone else.
      • You can't sublicense GPL code: it has to stay GPL
      • GPL3 is more compatible with other open licenses than GPL2
    • Example software projects licensed under the GPL Licenses:

Week 6

  • Register for FSOSS 2017 at table outside CS office at lunch time. $25 per student, includes lunch + swag.
  • 0.1 Release due in a few weeks (Oct 20)
    • Please add all your bugs/pull requests to DPS909 & OSD600 Fall 2017 Bug List
    • Work on your bugs, ask for help, help each other. Don't wait for things to happen, make them happen.
  • Git and GitHub Workflow
  1. Fork the project's repo. We'll refer to this as the upstream repo.
  2. Clone your Fork'ed repo locally. We'll refer to this as your origin (see below). git clone <git-url>
  3. Add a remote for the upstream repo: git remote add upstream <git-url>
  4. Confirm your remotes (you will need origin and upstream): git remote -v
  5. Setup your dev environment (e.g., npm install, pip install ..., build, etc.).
  6. Switch to your master branch: git checkout master
  7. Update your master branch with what's on the upstream repo's master: git pull upstream master
  8. Create a branch (sometimes called a Topic Branch) for your current work. Every bug, every experiment, everything you do gets its own branch: git checkout -b branch-name master
  9. Fix your code, add and commit your work on your topic branch: git commit -m "Fixing ..."
  10. Push your branch to your origin: git push origin <branch-name>
  11. Create a Pull Request (PR) against the upstream repo on GitHub. If you're fixing a bug (e.g., Issue 1234) say that in the description: Fixing #1234: .... Make sure you write a nice description of the fix, and how to test/confirm it.
  12. Fix any issues you hear back from reviewers by editing your branch, add, commit, and push again to the same branch on your origin: git push origin <branch-name>. Your changes will get added to the pull request
  13. Communicate with the reviewers and let them know what you've done: I fixed x, y, and z. Please review this again.
  14. Repeat until you fix all the issues they find in your code.
  15. Once they merge your branch, you can go back to your master and pull in those changes. You won't ever merge into master manually.
Retrieved from "https://wiki.cdot.senecapolytechnic.ca/w/index.php?title=DPS909_%26_OSD600_Fall_2017&oldid=128896"