264
edits
Calendar:Build: Difference between revisions
Jump to navigation
Jump to search
→Creating a Patch
XFallenAngel (talk | contribs) |
|||
| Line 202: | Line 202: | ||
If you changed UI, its always a good idea to add a screenshot and request ui-review from a ui-reviewer. See also the module ownership page. | If you changed UI, its always a good idea to add a screenshot and request ui-review from a ui-reviewer. See also the module ownership page. | ||
The review process usually starts off with a ui-review. It is possible, that the code reviewer will postpone the review until you have ui-review+, in case it is clear that the UI will stay as proposed. In the code review, the reviewer checks if the style fits the [[Calendar:Style_Guide|Style Guide]], and does a general check if the patch works as advertised. To ease review, you should make sure there are no (new) error console warnings or errors, and all tests pass (<code>cd $MOZILLA/obj*/calendar; make -C test check</code>). | |||
As soon as you have r+ from all reviewers (r+ means having a positive review, also known as r=''shortname''), you should fix everything that was requested, and upload a new patch. Unless you have CVS access yourself, the reviewer will generally take care of checking in the patch. If thats not the case, or he forgets to do so, you can add the <code>checkin-needed</code> keyword to the bug. | |||
After the patch is checked in and all aspects of the bug are taken care of, the reviewer will resolve the bug as FIXED. The patch will then be available in the next spun nightly. When it is available, it is always a good practice to test the functionality using the original steps to reproduce. If everything works as proposed, you can set the bug as VERIFIED. If any regressions show up, you should file a new bug and set the <code>regression</code> keyword on it. | |||
====Applying a patch==== | ====Applying a patch==== | ||