canmove, Confirmed users
2,850
edits
Partnering/Repacks/Policy and Process: Difference between revisions
Partnering/Repacks/Policy and Process (view source)
Revision as of 19:00, 25 June 2013
, 25 June 2013no edit summary
ChrisCooper (talk | contribs) |
ChrisCooper (talk | contribs) No edit summary |
||
| Line 14: | Line 14: | ||
Here is a generalized workflow: | Here is a generalized workflow: | ||
* clone the partner-repacks repo | * clone the [https://hg.mozilla.org/build/partner-repacks partner-repacks repo] | ||
** if you already have the repo, run <code>hg pull</code> instead | ** if you already have the repo, run <code>hg pull && hg update -r default</code> instead | ||
* make sure you don't have any existing changes in source clone by running <code>hg status</code> | * make sure you don't have any existing changes in source clone by running <code>hg status</code> | ||
* make any necessary changes to your partner repack files | * make any necessary changes to your partner repack files | ||
| Line 25: | Line 25: | ||
== Why create a patch? == | == Why create a patch? == | ||
All the partner repack configs are in [https://hg.mozilla.org/build/partner-repacks version control]. This lets us know when changes are made, who made them, and if something breaks, gives us the ability to back to a version that's known to work. | |||
If you're submitting changes for an existing repack, presumably you've already done some internal verification to make sure the changes are correct. By creating a patch of your changes as applied directly to the existing partner repacks configs in version control, you can be assured that your changes make it into the Mozilla system <em>exactly as you intend</em>. | |||
If you provide a zip bundle of your changes (or simply a new xpi) instead of a patch, the first thing a Mozilla release engineer must do is unpack that bundle and manually move the new files into position against a copy of the repo. Mozilla release engineers are careful, but we aren't perfect. This is a manual process, and prone to error. We also don't know what your intentions are with some config changes. If there is any ambiguity in the bundle, files could end up in the wrong place. | |||
Providing a exported patch against the configs in version control is the best way to ensure your changes are incorporated into the system as you expect. | |||
= Submitting a patch = | = Submitting a patch = | ||