159
edits
Changes
m
→Week 5
** 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], [httphttps://seanprashadmedium.com/blogseanprashad/first-contact.html -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
* [[DPS909/OSD600 Fall 2017 Lab 6/7 | Lab 6/7]]
== Week 7 , 8, 9 ==
* '''Changes to Semester'''
** 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:
*** 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>
