A3-GFB-diagnosis-plan
代写report | c++ | unity | assignment – 这是利用unity进行训练的代写, 对unity的流程进行训练解析, 包括了report/c++/unity等方面, 这个项目是assignment代写的代写题目
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 comm unity software project, once you have a firefox contribution under your belt youll 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:
- Read the bugzilla bug you have chosen carefully. (We have posted, in piazza under resources, the query URL to find reasonable candidate bugs.
- 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.
- 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.
- 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.
- 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
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 arent allowed to push to mozillas 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 thats 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 01234
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.
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 Mozillas 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.