Difference between revisions of "DPS909 & OSD600 Fall 2019"
(→Week 8) |
(→Week 8) |
||
Line 323: | Line 323: | ||
** Every week you'll need to contribute in some way to our open source project. This could be a small PR, reviewing code, adding some docs, writing a test, working in issues, doing research and writing background material, etc. | ** Every week you'll need to contribute in some way to our open source project. This could be a small PR, reviewing code, adding some docs, writing a test, working in issues, doing research and writing background material, etc. | ||
** Your lab blog post each week should discuss what you did | ** Your lab blog post each week should discuss what you did | ||
+ | |||
+ | * Readings for this week: [https://people.gnome.org/~jdub/bzr/planet/devel/trunk/ source code for Planet] |
Revision as of 15:26, 27 October 2019
Week 1
- Labs
- Weekly labs, typically done in class
- Labs are due on the Friday of the week they are assigned by midnight
- Marked using Pass/Fail scheme
- All labs must be completed to pass the course
- Lab 1 is available now
- Releases
- 4 releases, some with multiple bugs/PRs required, including participating in Hacktoberfest 2019
- Due Dates: Sept 20, Oct 31, Nov 20, Dec 6
- Chance to work on real code, real projects
- Big learning curve, lots of time required
- Amazing chance to gain experience, network, build your skills and resume
- Work with new and emerging technologies, gain exposure to tech outside the classroom
- Discussion/Readings
- Copyright (Copyright in Canada video)
- IANAL
- 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)
- Copyright (Copyright in Canada video)
- What is Open Source?
Week 2
- Blogging
- Add bio/profile info as you feel comfortable, including links to GitHub, social media, etc.
- Blog Post Tips:
- Use blog post titles that help a reader (or Google searcher) to know whether this is useful info to them
- Include links: a blog should connect different resources and ideas through your experience and learning
- Write in sections. Try to avoid a wall of text, with only a single paragraph. Consider using sub-headings, shorter paragraphs
- Use formatting for source code.
- One good source of blog posts on open source and software development is Hacker News. Some recent examples to look at for style:
- https://css-tricks.com/how-to-contribute-to-an-open-source-project/
- https://antoinevastel.com/javascript/2019/09/09/improving-obfuscator.html
- https://localghost.dev/2019/09/everything-i-googled-in-a-week-as-a-professional-software-engineer/
- https://randomascii.wordpress.com/2019/09/08/taskbar-latency-and-kernel-calls/
- 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
- No License
- What can you do with code you find that has no license?
- what can I, can't I do?
- Proprietary Licenses
- Public Domain
- SQLite, which is now used by literally everybody, see http://www.sqlite.org/famous.html
- Unlicense
- BSD License
- Family of Licenses, including 2-Clause BSD, 3-Clause BSD (aka New BDS), 4-Clause BSD
- "Why you should use a BSD style license for your Open Source Project"
- BSD Licenses code is usually compatible with other open/closed code, when you want to mix them.
- Example software projects licensed under the BSD License:
- Summary:
- You need to retain the license and copyright notice
- You can use it commercially or non-commercially (privately)
- You can distribute it freely
- You can modify it freely
- Discussion of projects found for Lab 1
- Lab 2
- Release 0.1 due Mon, Sept 23
Week 3
- Readings/Resources
- Introducing git and GitHub
- Content Addressable Filesystem and Snapshots
- Distributed: Local vs. Remote development
- .git directory
- Content Integrity, SHAs (Secure Hash Algorithm)
-
git init
-
echo 'test content' | git hash-object -w --stdin
-
ls .git/objects
-
git cat-file -p d670460b4b4aece5915caf5c68d12f560a9fe3e4
-
- Blobs, Trees, and Commits
- Branches,
master
- Working Directory, Staging Area, Repository
- What do these commands really do?
-
git clone url-to-git-repo
-
git add file.txt
-
git status
-
git rm file.txt
-
git commit -m "Added file.txt"
-
- Remotes,
origin
,upstream
- Filing and Fixing a bug: a cookbook approach
- set up git and GitHub
- https://help.github.com/ has lots of great articles to help you. You can also view video guides or read the printed guides
- setup your username in git
- setup your email address in git
- specify which editor git should use, for example you can use vscode
- setup line endings (CRLF vs. LF) in git, extra notes for Windows users
- setup ssh keys for GitHub
- In GitHub, create a fork of the repo you want to work on
- On your computer, clone your forked repo
- On your computer, add a remote named "upstream" for the original repo (vs. your fork)
- On GitHub, find or create an Issue for the change you want to make
- On your computer, create and checkout a branch for your work, e.g., issue-1234 for Issue #1234
- On your computer, make code changes, test them, add, and commit on your branch. Repeat as necessary.
- On your computer, push your changes (commits) to your fork (origin)
- On GitHub, create a Pull Request for your changes to get sent to the upstream repo
- On your computer, fix any problems pointed out by your reviewer(s), add the file(s), commit, and push again to update your pull request
- set up git and GitHub
- Release 0.1 due Mon, Sept 23
Week 4
- Blogging
- Why Blogging is Awesome
- Keep reading the Planet, there are great posts there
- Learning Licenses: MIT
- MIT License
- The MIT License, Line by Line
- One of the most widely used licenses in Open Source
- Like the BSD License, nothing about patents (created before software was patentable in the US)
- Example software projects licensed under the MIT License:
- "Do Good" forks of MIT:
- JSON License with a great overview and history here.
- Hippocratic License
- Recent situation with Chef-Sugar, Chef and ICE Contract. Update from today
- More Git
- Git Walkthrough Part I
- Git Walkthrough Part II
- Upstream and keeping your
master
branch up-to-date
- Release 0.1 due Mon, Sept 23. Any issues you need help with?
- Release 0.2
- Lab 3
- Startup Open House Event Tonight, Thurs Sept 26 4-8
Week 5
- Forking vs. Merging
- Anyone can fork, not everyone can get work merged back in
- My Repo: my house my rules
- Some famous Forks
- Firefox from Mozilla Suite
- WebKit from KDE's KHTML
- Blink from WebKit
- Ubuntu from Debian
- Sun's StarOffice became OpenOffice became LibreOffice
- WordPress from Cafelog
- MariaDB from MySQL
- FireOS (Amazon for Kindle) from Android
- io.js from node.js, which eventually became the official node.js
- Example Fork
- Semantic UI
- Fomantic UI - "Fomantic was created to continue active development of Semantic-UI and has the intent to be merged back into the master repository once active development can restart."
- Merging with git
- Where
git branch
splits histories apart,git merge
brings them back together - Understanding DIFFs and Patch files
-
git diff
,git show
,git log -p
, etc. to show DIFFs - Pull Requests also have links to get the raw .diff and .patch
- How to read a DIFF file
-
- Types of Merges: Fast Forward, Recursive Merges are the most common
-
--ff-only
to force a fast-forward (only the branch pointer is moved, no new commit is created) - 3-way merges: two branch commits with a common ancestor (new commit is created with multiple parents)
- Can have any number of parents though: one of the larges is a 66 commit octopus merge in the Linux kernel
-
- How to merge
- start with a clean working directory
-
commit
your work if you can; or -
stash
(git stash list
,git stash show
,git stash pop
)
-
- checkout the branch you want to merge into
-
git merge branch_to_merge_into_this_branch
- start with a clean working directory
- Various flags and commands to know:
-
git merge --squash
-
git merge --abort
-
git merge --continue
-
git branch -d
-
- Merge Conflicts
- Conflict markers
<<<<<<<<<
,=============
,>>>>>>>>>>>>
- Conflict markers
- Doing big merges in git
- Where
- TODO
- Merging 3 PRs example
- Release 0.2
- Lab 4 - Complete your first Hacktoberfest PR, and write your first blog post about your fix. See guidelines in the Release 0.2 page. Place both links in a new section under the Submission section.
Week 6
- 0.2 Updates
- How's it Going?
- Things I read in your blog posts:
- Setting up projects takes time, research (Docker, Gatsby, Makefile, Gems, npm builds etc)
- Trouble running projects
- Watch Windows line ending issues
- Need to fix things the way the project wants vs. how you want
- Include links in your blog posts when you talk about things
- Things I read in your blog posts:
- Interesting projects you've found?
- Stats for Week 1
- 44 PRs: +3,358/-941 lines of code across 178 files in 37 repositories
- 19 have already been merged
- 21 people didn't get Lab 1 done (no PR/blog)
- How's it Going?
-
git commit --amend
- Add to, correct, or otherwise alter your previous commit and/or comment message
- Use
--no-edit
to leave the commit message alone
-
git rebase branch
- Replay commits on a new base branch/commit
- Process goes like this:
- git finds a common ancestor commit of the branch you're on, and the one you're rebasing onto
- git calculates DIFFs for each, saves them to disk
- git checks out the commit you want to branch onto, and begins to replay those diffs one by one
- if there is a merge conflict, the rebase pauses so you can fix things
- use
git rebase --continue
orgit rebase --abort
to move forward after such a pause - use
git rebase --skip
to ignore the current commit and keep going
- Never rebase commits that are shared publicly in another repo. Only do it on commits you own locally (e.g., a topic branch you are working on)
- Don't use rebase to get rid of commits in a public branch, use
git revert commit-sha
instead to apply an inverse commit - If you rebase a branch you've pushed (e.g., for a pull request), when you push, use
git push origin branch-name -f
(f means force and will overwrite) -
git rebase -i
for interactive rebase- shows a script of all commits in reverse order (order they will be replayed). You can hand edit this to remove, re-order, or combine commits
- You can squash on the same branch by rebasing on
HEAD~n
where n is how many commits back from HEAD to go
-
git cherry-pick SHA
to add a commit to the current branch
Week 7
- Continue working on 0.2
- Discussion of any issues/questions you have
- End of Week 2 Stats:
- +15,819/-8,733 LOC in 414 files across 116 PRs to 89 Repos. 62 merged (53%) already
- Interesting stories from PR #2
- Open Source Case Study: Visual Studio Code
- https://code.visualstudio.com/
- https://github.com/Microsoft/vscode
- https://en.wikipedia.org/wiki/Visual_Studio_Code
- Technologies
- Electron
- Monaco Editor
- TypeScript
- xterm.js
- node.js, express, and hundreds of JavaScript modules
- Looking for Contribution Opportunities in Dependencies
-
yarn
- Look at
node_modules
and examine the projects and issues (955 deps) - Are there any bugs we could fix?
-
- Fixing a Bug in VSCode Walkthrough:
Week 8
- Continue working on 0.2
- Discussion of any issues/questions you have
- End of Week 3 Stats:
- +30,402/-14,751 LOC in 688 files across 178 PRs to 127 Repos. 89 merged (50%) already
- Interesting stories from PR #3
- Discussion of OSD & DPS909 Fall 2019 - Release 0.3 and OSD & DPS909 Fall 2019 - Release 0.4
- Creating an Open Source Project as a group of 50+
- Telescope project, see the project Overview doc
- Seneca Open Source Slack for async communication (sign-up with your @myseneca.ca email)
- Wrap-up and Discussion of Hacktoberfest 2019
- Discussion of Labs for the rest of the term.
- Every week you'll need to contribute in some way to our open source project. This could be a small PR, reviewing code, adding some docs, writing a test, working in issues, doing research and writing background material, etc.
- Your lab blog post each week should discuss what you did
- Readings for this week: source code for Planet