2019/10/13 ӥ܌5)40A3-GFB-diagnosis-plan
ᒫ 1 ᶭҁو 5 ᶭ҂https://q.utoronto.ca/courses/111538/assignments/188466
A3-GFB-diagnosis-plan
Due Nov 15 by 5pm Points 7
Goal
The goal of this assignment is to learn how to contribute a fix to firefox. Given that firefox is an excellent
representative of a well-run community software project, once you have a firefox contribution under your belt
you’ll be good to go for many other projects too. In fact, many industry teams have adopted processes very
similar to the larger open source projects, so you likely have a head start on your internships or PEY.
Learn about Mozilla's firefox and Servo GFB program
Read Josh Matthews lecture (https://www.joshmatthews.net/mozgfb19/#) to class (week 3) about GFB and
Servo bugs. (It includes the links to query mozilla's bugbase)
Procedure
You will create a patch and write a report that documents your progress through the bug fixing process.
Upon completing these you will have everything you need to actually contribute your patch to mozilla. If you
are not highly confident of your understanding of the issue you might want to discuss with it with your TA or
instructor first.
The steps you should follow are:
1. Read the bugzilla bug you have chosen carefully. (We have posted, in piazza under resources, the query
URL to find reasonable candidate bugs.
2. Sign up for the bug in the google sheet called csc302-A3-utorid-to-bugzilla-URL-signup-sheet. At least in
the early going one bug per student! You will find a link to the sheet on the quercus "SignupSheets"
page.
3. Read the Mozilla how-to submit a patch guide (https://developer.mozilla.org/en-
US/docs/Mozilla/Developer_guide/How_to_Submit_a_Patch) . This is a large document and you should study
it carefully.
4. Diagnose the problem. In many cases the bug report will spell out what is wrong and what you should do
to fix it. You must describe why the issue is worth resolving and thus what value your work will add to the
mozilla project.
5. Describe a testing procedure or manual inspection process that will show you have fixed the bug. That
is, describe the behaviour or artifact that is wrong before your patch is applied and how it should appear
2019/10/13 ӥ܌5)40A3-GFB-diagnosis-plan
ᒫ 3 ᶭҁو 5 ᶭ҂https://q.utoronto.ca/courses/111538/assignments/188466
You can use git and github to submit your work, much like you did in 301. It turns out that mozilla maintains a
github shadow of mozilla-central called https://github.com/mozilla/gecko-dev
(https://github.com/mozilla/gecko-dev) . (gecko-dev remains read-only to moz devs -- they still use hg to push
their work. Further, first timers aren’t allowed to push to mozilla’s hg repo-- they contribute by attaching a
patch file to the bugzilla entry they are trying to address. )
Before you can submit your patch, we would like to look at your work. A github Pull Request is a very
convenient way to see what changes you have made, so that’s probably the most convenient way for you to
share your work with your TA. To do this you would fork gecko-dev, create a PR, and share this with your TA.
A complication of using github is that you cannot privately fork gecko-dev, hence your commits will be
public. If this makes you uncomfortable, you are under no obligation (ever) to do universith course work in
public.
Looking forward to A4, when you are ready to submit your patch to mozilla, you will use hg (or git) diff to
create the patch, and then run a specific mozilla script to transform your git patch into a hg patch.
To create a useful patch, you obviously must be working on the very latest mozilla. You should sync your
fork (https://help.github.com/articles/syncing-a-fork/) before creating your patch.

Evaluation/Rubric
We will evaluate your deliverables using the following rubrics.

Component 0 1 2 3 4
Diagnosis. Clearly describes the problem and what needs to be done to solve it
Test plan: Clearly articulates how to demonstrate that the problem has been fixed
Fix: Appropriate technical solution of the bug, in line with any suggestions from the mentor and
mozilla guidelines.
Collaboration: Clear and appropriate communication with mozilla mentor and/or teaching staff
Patch and comments: crystal clear commit message and explanatory comment in bugzilla.
2019/10/13 ӥ܌5)40A3-GFB-diagnosis-plan
ᒫ 5 ᶭҁو 5 ᶭ҂https://q.utoronto.ca/courses/111538/assignments/188466
you will need.
Note that the above page links to How can I generate a patch (https://developer.mozilla.org/en-
US/docs/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F) . This page,
in turn, has a section explaining “How can I generate a patch for somebody else to check-in for me”. Follow
that.
There even is a section titled “I'm all used to Git, but how can I provide Mercurial-ready patches?” which
describes how to convert a git patch to a hg patch.
Also, there is a Reviewer Checklist (https://developer.mozilla.org/en-
US/docs/Developer_Guide/Reviewer_Checklist) , which includes several important suggestions. For beginners
like us digesting and following the Style Guide (https://developer.mozilla.org/en-
US/docs/Mozilla/Developer_guide/Coding_Style) requires a lot of attention. Caution: if you are using the
Eclipse IDE the default C/C++ code formatter does not match Mozilla’s style guide.

Even more Links
https://wiki.mozilla.org/Contribute/Coding/Mentoring (https://wiki.mozilla.org/Contribute/Coding/Mentoring)
https://github.com/blog/967-github-secrets (https://github.com/blog/967-github-secrets) check out the .patch
URL hint.