Patches and pushes

Now that you've made your productization selections, you may be interested in learning the technical aspects behind productization by creating a productization patch. Below you'll find instructions on creating a patch and pushing it to your repository.

Patchify

  1. Search plugins are found in browser/searchplugins. Each plugin is stored as an XML file, with list.txt containing the names of each plugin.

Here is an example search plugin file using French Yahoo.

<SearchPlugin xmlns="http://www.mozilla.org/2006/browser/search/">
<ShortName>Yahoo</ShortName>
<Description>Yahoo Search</Description>
<InputEncoding>UTF-8</InputEncoding>
<Image width="16" height="16">data:image/x-icon;base64,R0lGODlhEAAQAJECAP8AAAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIplI+py+0NogQuyBDEnEd2kHkfFWUamEzmpZSfmaIHPHrRguUm/fT+UwAAOw==</Image>
***This tag is optional***<Url type="application/x-suggestions+json" method="GET"
     template="http://ff.search.yahoo.com/gossip?output=fxjson&amp;command={searchTerms}" />***
<Url type="text/html" method="GET" template="http://search.yahoo.com/search">
  <Param name="p" value="{searchTerms}"/>
  <Param name="ei" value="UTF-8"/>
  <MozParam name="fr" condition="pref" pref="yahoo-fr" />
</Url>
<SearchForm>http://search.yahoo.com/</SearchForm>
</SearchPlugin>

 

  1. Create XML files for each search plugin preference following the above example. For references on how each tag functions, visit the OpenSearch wiki page and the MozSearch wiki page. The pages are old (I mean, Firefox 2???), but still accurate.
  2. Each plugin has an icon image which is linked within the XML file as an URI ID. Upload your plugins icon image to Data Kitchen to obtain its URI ID and add to the XML file within the Image tag.
  3. In list.txt, add the search plugin's XML filename (without extensions) on a new line and save. Note that if your team selects a local version of an already default plugin (e.g., Wikipedia), the XML filename should include the locale code (e.g., Wikipedia-es).
  4. Create a patch of the searchplugins directory by entering the following command in your command-line tool, where mypatch.diff is where you give your patch a name:
$ hg add mozilla/browser/searchplugins/
$ hg diff mozilla/browser/searchplugins/ > mypatch.diff
  1. Attach your patch file to the bug by clicking the "Add an attachment" link. Once attached and labeled as a patch, open the attachment details.
  2. In the attachment details, select the ? from the dropdown menu next to the review flag. This will display a text box to assign the review to someone.
  3. Enter :flod as the Requestee.

Review, commit, & land

  1. Address any review comments made by the reviewers and update the patch until it receives an r+ rating.
  2. If the r+ is "with nits" (i.e., that's short for nit-picky requests), fix those before committing. Also, no new patch attachment will be needed.
  3. Commit the patch to your Aurora repo.
    1. Only commit the changes you have reviewed.
    2. Use a commit message that mentions the bug number, describes the change, and mentions the reviewer. For example:
hg ci -m "bug 654321, copied the comment from the doc without reading, r=nobody" path-to-changed-files
  1.  Close the bug, copying the url to your change in the closing comment. Write up something like this for your comment:
Landed this on aurora, http://hg.mozilla.org/releases/l10n/mozilla-aurora/ab-CD/rev/adfe1234feac, marking FIXED.
  1. Update your sign-offs on the l10n dashboard to include the change into the next release.

And that's it! It can be considered a bit complicated at first, but after you do it the first time, it gets easier and easier after that :-)

Document Tags and Contributors

Tags: 
 Last updated by: teoli,