Partnering/Repacks/Policy and Process: Difference between revisions

← Older edit

Partnering/Repacks/Policy and Process (view source)

Revision as of 18:43, 19 May 2017

3,329 bytes removed , 19 May 2017

Removing old Mercurial info

MikeKaply

218

edits

@@ Line 51: / Line 51: @@
 === Version Control ===
-Mozilla keeps all of our partner repack configuration files under version control in [http://mercurial.selenic.com/ Mercurial (hg)].
+Mozilla keeps all of our partner repack configuration files under version control in [https://github.com/ GitHub].
-If you are unfamiliar with hg, Mozilla has some good dev resources for getting started:
-* [https://developer.mozilla.org/en-US/docs/Mercurial The basics]
-* [https://developer.mozilla.org/en-US/docs/Developer_Guide/Source_Code/Mercurial Getting Mozilla Source Code Using Mercurial]
-* [https://developer.mozilla.org/en-US/docs/Mercurial_FAQ Using Mercurial]
-The partner-repacks repository (repo) is publicly available here: https://hg.mozilla.org/build/partner-repacks
+When a partner build is created, you will be given access to a repository that corresponds to your repack.
 === Creating a patch ===
-This section assumes that you are already familiar with the basics of hg.
+This section assumes that you are already familiar with the basics of GitHub.
 Here is a generalized workflow:
-* clone the [https://hg.mozilla.org/build/partner-repacks partner-repacks repo]
+* fork the repository
-** if you already have the repo, run <code>hg pull && hg update -r default</code> instead
+* create a patch
-* make sure you don't have any existing changes in source clone by running <code>hg status</code>
+* submit a pull request
-* make any necessary changes to your partner repack files
-** make sure you run <code>hg add</code> to add new files, or <code>hg remove</code> if you are removing files
-* commit changes to your local repository, <code>hg commit ...</code>
-* export the changeset using <code>hg export REV</code>, where REV is the revision number of the changeset, e.g.:
- $ PARTNERNAME=aol
- $ hg export -g tip > repack_config_changes_for_$PARTNERNAME.diff
-=== 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 revert back to a known-good version if there are problems.
-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.
+After a pull request has been merged, you can request a build on Bugzilla if the update is urgent, otherwise you should wait for the normal Mozilla build cycle.
-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 ===
-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:
@@ Line 92: / Line 68: @@
 * Or use this convenient template: [https://bugzilla.mozilla.org/enter_bug.cgi?alias=&assigned_to=nobody%40mozilla.org&attach_text=&blocked=&bug_file_loc=http%3A%2F%2F&bug_ignored=0&bug_severity=normal&bug_status=NEW&cc=mconnor%40mozilla.com&cf_blocking_b2g=---&cf_blocking_fennec=---&cf_crash_signature=&cf_status_b2g18=---&cf_status_b2g_1_1_hd=---&cf_status_b2g_1_2=---&cf_status_b2g_1_3=---&cf_status_b2g_1_4=---&cf_status_firefox26=---&cf_status_firefox27=---&cf_status_firefox28=---&cf_status_firefox29=---&cf_status_firefox_esr24=---&cf_tracking_b2g18=---&cf_tracking_b2g_v1_2=---&cf_tracking_b2g_v1_3=---&cf_tracking_firefox26=---&cf_tracking_firefox27=---&cf_tracking_firefox28=---&cf_tracking_firefox29=---&cf_tracking_firefox_esr24=---&cf_tracking_firefox_relnote=---&cf_tracking_relnote_b2g=---&comment=REMINDER%3A%20Please%20provide%20a%20summary%20of%20the%20changes%20contained%20in%20this%20diff.&component=Releases%3A%20Custom%20Builds&contenttypeentry=&contenttypemethod=autodetect&contenttypeselection=text%2Fplain&data=&dependson=&description=&flag_type-4=X&flag_type-481=X&flag_type-607=X&flag_type-791=X&flag_type-800=X&flag_type-803=X&form_name=enter_bug&keywords=&maketemplate=Remember%20values%20as%20bookmarkable%20template&op_sys=All&priority=--&product=Release%20Engineering&qa_contact=bhearsum%40mozilla.com&rep_platform=All&requestee_type-4=&requestee_type-607=&requestee_type-791=&requestee_type-800=&short_desc=Partner%20repack%20changes%20for%20%24PARTNERNAME&status_whiteboard=%5Bpartners%5D&target_milestone=---&version=other 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.
+Please remember to change $PARTNERNAME in the bug summary to reflect the partner you requesting a build 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.