Partnering/Repacks/Policy and Process: Difference between revisions

Partnering/Repacks/Policy and Process (view source)

Revision as of 18:33, 25 June 2013

1,430 bytes added , 25 June 2013

→‎Submitting a patch

ChrisCooper

canmove, Confirmed users

2,850

edits

@@ Line 25: / Line 25: @@
 = Submitting a patch =
-TODO: bug filing template
+The best way to submit a change to an existing partner repacks is via [https://bugzilla.mozilla.org/ Bugzilla].
+If you're new to bugzilla, the first step is to [https://bugzilla.mozilla.org/createaccount.cgi create an account].
+To expedite the bug filing process, I've created a template that partners can use to quickly file bugs under the correct product & component:
+* [http://mzl.la/136S1Gq Partner repack config change bug template]
+Please remember to change $PARTNERNAME in the bug summary to reflect the partner you are submitting the config change for.
+Add your exported diff of changes from hg as an attachment to the bug.
+By default, you will automatically receive updates for any action taken on your bug. You can change which updates you receive in your [https://bugzilla.mozilla.org/userprefs.cgi Bugzilla Preferences].
+== Why use Bugzilla? ==
+Mozilla release engineering uses bugzilla to track everything. If you don't submit your patch via bugzilla, the first thing the Mozilla release engineering team does is file a bug to cover the work to be performed and attach your submitted patch/bundle.
+By filing your request directly in bugzilla, you automatically notify the correct people, have a record of your patch submission, and get updates whenever some performs an action on your ticket. You save the Mozilla team manual, potentially error-prone work, and get more ongoing insight into the process and the status of your request.