159
edits
Changes
m
→Week 5
* 0.1 Release
** Advice: '''you''' have to make things happen
** If you don't have your bugs assigned yet, please come see me, talk to me on Slack, or email me ASAP.
** Make sure you have reached out to the community around your bugs (irc, Slack, Mattermost, GitHub, mailing list, etc.)
** Please add all your bugs/pull requests to [[DPS909 & OSD600 Fall 2017 Bug List]]
*** Help one another, learn from one another, inspire one another: [http://www.danepstein.ca/its-time-to-fix-open-source-bugs/ Dan Epstein], [https://michaelpierreblog.wordpress.com/2017/09/29/the-search-for-bugs-and-contribution-to-the-open-source-community/ Michael Pierre], [https://medium.com/seanprashad/first-contact-a28cfe776840 Sean Prashad], [http://assmith2017.blogspot.com/2017/10/bugs-on-open-source.html Azusa Shimazaki], [http://mylyfeincode.blogspot.com/2017/09/finding-bug-is-harder-than-you-think.html Jiel Selmani]
* Learning Licenses: GPL
*** [http://help.github.com/ Github documentation]
*** [https://desktop.github.com/ GitHub Desktop]
* [[DPS909/OSD600 Fall 2017 Lab 5 | Lab 5]]
== Week 6 ==
* Register for [http://fsoss.ca 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'''
# '''Fork''' the project's repo. We'll refer to this as the '''upstream''' repo.
# '''Clone''' your '''Fork''''ed repo locally. We'll refer to this as your '''origin''' (see below). <code>git clone <git-url></code>
# '''Add''' a '''remote''' for the '''upstream''' repo: <code>git remote add upstream <git-url></code>
# Confirm your remotes (you will need '''origin''' and '''upstream'''): <code>git remote -v</code>
# '''Setup''' your dev environment (e.g., <code>npm install</code>, <code>pip install ...</code>, build, etc.).
# '''Switch''' to your '''master''' branch: <code>git checkout master</code>
# '''Update''' your '''master''' branch with what's on the '''upstream''' repo's '''master''': <code>git pull upstream master</code>
# '''Create''' a '''branch''' (sometimes called a '''Topic Branch''') for your current work. Every bug, every experiment, everything you do gets its own branch: <code>git checkout -b branch-name master</code>
# '''Fix''' your code, '''add''' and '''commit''' your work on your topic '''branch''': <code>git commit -m "Fixing ..."</code>
# '''Push''' your '''branch''' to your '''origin''': <code>git push origin <branch-name></code>
# '''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: <code>Fixing #1234: ...</code>. Make sure you write a nice description of the fix, and how to test/confirm it.
# '''Fix''' any issues you hear back from reviewers by editing your branch, '''add''', '''commit''', and '''push''' again to the same branch on your origin: <code>git push origin <branch-name></code>. Your changes will get added to the pull request
# '''Communicate''' with the reviewers and let them know what you've done: <code>I fixed x, y, and z. Please review this again</code>.
# '''Repeat''' until you fix all the issues they find in your code.
# 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.
* [[DPS909/OSD600 Fall 2017 Lab 6/7 | Lab 6/7]]
== Week 7, 8, 9 ==
* '''Changes to Semester'''
** Removal of Release 0.3 from Graded Work. You will only be expected to complete two releases instead of three: 0.1 and 0.2.
** Grading will now be as follows:
*** Release 0.1 - 35% (up from 25%)
*** Release 0.2 - 35% (up from 25%)
*** Blog - 15% (no change)
*** Labs - 15% (up from 10%)
** Due Dates
*** Release 0.1 due by Tues Nov 28
*** Release 0.2 and any outstanding Labs due by midnight Fri Jan 5th
** Revised Class schedule:
*** Tues Dec 19, final in-class session together
*** Thurs Dec 21, final on-line lab
*** Jan 2-5, no formal class time together. Complete outstanding labs, release work. I'll be available online only via Slack, Email, GitHub, etc.
* '''TODO'''
** Complete and Submit [[DPS909/OSD600_0.1_Release|0.1 Release]] by next Tues Nov 28th.
** Update [[DPS909 & OSD600 Fall 2017 Bug List]] with any new bugs you've done since we were apart
** Start thinking about/taking to Dave about what you'll do for your second release. We'll discuss next week.
* Three Questions:
** '''What's a victory you've had already?''' Bug you fixed? Project you contributed to? Tech you mastered? Something you learned that used to be hard?
** '''What's something you're finding tricky?''' Something we should cover in class? Something you have to do for a bug, a tool that you don't fully understand, an issue with some process?
** '''What's an open source goal you have for yourself before the end of term?''' Project you want to contribute to? Technique you want to master? Community you want to join? Something you want to learn/accomplish?
* Continuous Integration (CI)
** Automate and Test everything
** Have bots integrate, verify, and test all parts of a project every time you make a change. For both large and small changes.
** Revert changes that "break the build"
** Produce "nightly" or "staging" style build artifacts the community can test against
** Automate deployment tasks per commit
** Make it less painful for a large community to work on the same code without sacrificing stability.
* Open Source CI
** Most projects use one of [https://travis-ci.com/ TravisCI], [https://circleci.com/ CircleCI], [https://www.appveyor.com/ AppVeyor], etc.
** https://twitter.com/kelseyhightower/status/932654629648719872 - there is no one right way to do this, just a million variations you'll encounter in the wild.
** Free for Open Source Projects
** Integrates with GitHub, build per commit or pull request, reports back to GitHub PRs.
** Used for Building, Testing, Linting, and Deployment
* TravisCI
** See [https://docs.travis-ci.com/user/getting-started/ Getting Started] and [https://docs.travis-ci.com/user/for-beginners/ Core Concepts]
** You need an automated setup, build, and test system for your project.
** Create an Account with TravisCI and Enable an Integration for your GitHub repo.
** TravisCI is configured for a project via a ''travis.yml'' file
** The ''travis.yml'' file tells TravisCI how to setup a virtual container to build/test your code, and which steps to use in order to determine if things are working
** Example 1: Thimble
*** https://github.com/mozilla/thimble.mozilla.org/blob/master/.travis.yml
*** https://github.com/mozilla/brackets/blob/master/.travis.yml
*** https://travis-ci.org/mozilla/thimble.mozilla.org
*** https://travis-ci.org/mozilla/brackets
*** https://bramble.mofostaging.net/en-US/
** Example 2: Activity Stream
*** https://github.com/mozilla/activity-stream/blob/master/.travis.yml
*** https://travis-ci.org/mozilla/activity-stream
** Example 3: Firefox JavaScript Debugger
*** https://github.com/devtools-html/debugger.html/blob/master/.travis.yml
*** https://travis-ci.org/devtools-html/debugger.html
* [[DPS909/OSD600 Fall 2017 Lab 8 | Lab 8]]
* [[DPS909/OSD600 Fall 2017 Lab 9 | Lab 9]]
* [[DPS909/OSD600 Fall 2017 Lab 10 | Lab 10]]
* [[DPS909/OSD600 Fall 2017 Release 0.2 | Release 0.2]]
* [https://github.com/humphd/learn-travis Learn Travis Walkthrough repo]
== Week 10 ==
* '''Code Reading'''
** Discussion:
*** Why read source code at all?
*** Imagine having to fix a bug in a multi-million line program, where do you start?
*** Top-down, bottom-up, something else?
*** Is adding a feature different from fixing a bug?
* DOs and DON'Ts
** DO approach things with optimism. You can do this, don't start by being overwhelmed
** DON'T get bogged down in details (at first)
** DO open a million tabs, skim through things fast, start to narrow your focus
** DON'T try to understand everything
** DO formulate questions: questions to research in the code (who calls this? where is this defined?), questions to ask devs
** DON'T be afraid to start down different paths in parallel. Walk away when you get frustrated, come at it again from a new angle
** Goal Oriented vs. For Enjoyment
** Build system and Tests play a role in helping you do experiments
*** Experiments (can you "break" the code?)
*** Tests as Documentation (can you alter a test in order to get the tests to fail?)
** Debuggers, Breakpoints, Logging, even <code>printf</code> are your friends
** "Reading" by Search vs. Linear Progression
** Source Code Indexers
** Find "footholds" for climbing by looking at parallel bugs (same component, similar feature design, bugs in similar code)
** Source Code Archaeology
** Closed Bugs/PRs/Issues help us understand a package of changes, why they happened, which files/lines were changed, who was involved, and when they happened.
** History of a file
** History of a Line: "blame" (e.g., <code>git blame</code>)
** Parallel Implementations (e.g., competing projects, implementations in other languages, forked projects)
* Open Source Browsers
** '''WebKit''': [https://trac.webkit.org/browser WebKit Trac], [https://bugs.webkit.org/ Bugzilla]
** '''Chromium''': [https://cs.chromium.org/ Search] or [https://chromium.googlesource.com/chromium/src.git Browse], [https://bugs.chromium.org/p/chromium/issues/list Bugs]
** '''Mozilla''': [https://dxr.mozilla.org/mozilla-central/source/ Mozilla DXR], [https://bugzilla.mozilla.org/ Bugzilla]
* Case Studies
** <code>document.cookie</code>: [https://developer.mozilla.org/en-US/docs/Web/API/Document/cookie MDN docs]
** <code>text_transform: capitalize</code>: [https://drafts.csswg.org/css-text-3/#text-transform CSS spec for text-transform]
** <code>video.volume = newVolume;</code>: [https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/volume MDN docs], [https://html.spec.whatwg.org/#dom-media-volume HTML Spec on media volume]
* [[DPS909/OSD600 Fall 2017 Lab 11 | Lab 11]]
== Week 11 ==
* git loose ends
** merge vs. squash. What they do, when to use, when not to, common workflows
** squashing example with https://github.com/mozilla/brackets/pull/900
** rebase example with merge conflict https://github.com/mozilla/brackets/pull/850
** cherry-pick example with upstream fixes https://github.com/adobe/brackets/commit/baf964e123a5b0a8c34ef3dc58e657c2c75d7b7e, https://github.com/adobe/brackets/commit/f08ef99dc9b1384bc72ae42c5e17d20254d18ed6
* Discussions
** [https://twitter.com/dan_abramov/status/936427676579004416?s=03 Open Source and Work Opportunities]
** [https://twitter.com/search?src=typd&q=%22looking%20glass%22%20firefox Looking Glass] and the [https://www.cnet.com/news/mozilla-backpedals-after-mr-robot-firefox-misstep/?ftag=COS-05-10aaa0g reaction], and [https://blog.mozilla.org/firefox/update-looking-glass-add/ response]
* Finally, we return to our first question:
** "What is open source?"
** What do you think now?
** How has your answer stayed the same/changed?
** What are your next steps in open source now that you've gotten started?
** [https://github.com/blog/2480-github-s-technology-predictions-for-2018 GitHub's 2018 predictions]:
<pre>
Open source will keep climbing the stack
A decade ago, Linux was a big deal. Now it’s standard. Back in the day, companies like Amazon, Google, and Microsoft were forced to build their own, proprietary tools because no other software existed to meet their needs. Many of these frameworks have since been open sourced—and other open source technologies, like Kubernetes, are becoming integral to developers' workflows. This shift is changing what companies are investing in, making open source software traditional software's biggest competitor.
</pre>