Partnering/Repacks/Policy and Process: Difference between revisions

Latest revision as of 18:43, 19 May 2017

Overview

This document outlines the high level policy for Firefox custom bundles, applicable to all custom distributions of Firefox produced by Mozilla for partners. Some of these requirements may be in conflict with existing written agreements, otherwise all existing distributions are expected to come into compliance with these requirements as soon as possible, and no later than June 30, 2015. Some requirements will come into place over the first half of 2015, in order to allow time for any required changes to products or processes.

For more information on becoming a Mozilla distribution partner, please refer to Becoming a Mozilla Distribution Partner.

Review Process and Timelines

Changes to custom configurations must be submitted no later than three weeks prior to the next regularly scheduled release, in order to be included in custom builds for that release.
- After this time, only significant bug fix changes will be considered for that release.
Beta builds are produced twice weekly, and upon approval reviewers will advise as to the next set of builds which will contain the approved changes.
Release candidate builds will generally be available one week prior to the target release date.
Partners are not permitted to distribute custom builds prior to the official Mozilla release.

For an overview of the change submission process, please refer to the instructions below.

Build Identification

Each unique configuration must be identified separately through a unique distribution ID.
For each new custom distribution, partners must clearly identify the target market(s) and languages for the desired configuration, as well as any other reasonable information necessary to understand the scope for any potential distribution.

Quality Requirements

Mozilla will review and approve all changes to custom configuration. Mozilla does not do formal Quality Assurance testing on custom bundles. Distributors are expected to verify that all of their customizations are working as intended in the provided builds.

Preferences

All preference changes not explicitly required under existing agreements must be approved by Mozilla.
No preference changes will be permitted that negatively impact the security or user experience of end users.
Except where expressly covered by the distribution agreement, search default changes shall not be approved.

Bookmarks

Bookmarks must be clearly labelled, and should link only to relevant content from the partner in question.

Add-ons

Effective as of Firefox 39

All bundled add-ons to be included with a custom distribution must already be signed in accordance with Mozilla's add-on signing policy. This will require that all bundled add-ons have passed full review through the AMO review process, whether that add-on is or is not distributed on AMO itself.

The process for submitting add-ons that are not to be hosted on AMO will be announced in the near future, and should be live in May 2015. If an add-on is already hosted on AMO at that time, signing will happen automatically. Distribution partners will have priority for reviews, please contact Partner Support for more details.

Revenue-impacting Changes

Effective as of Firefox 38

Firefox has a number of features that have revenue-bearing components, generally in the form of partnerships or paid placements. These features include Search, Tiles, and other potential features. Except where otherwise agreed under a formal custom distribution agreement, no changes shall be permitted that negatively impact the revenue potential of these features. This includes changes that would be otherwise permitted within the scope of an add-on under the AMO policy.

Submitting Changes

Version Control

Mozilla keeps all of our partner repack configuration files under version control in GitHub.

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 GitHub.

Here is a generalized workflow:

fork the repository
create a patch
submit a pull request

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.

To expedite the bug filing process, I've created a template that partners can use to quickly file bugs under the correct product & component:

Product: Release Engineering, Component: "Releases: Custom Builds"
Or use this convenient template: Partner repack config change bug template

Please remember to change $PARTNERNAME in the bug summary to reflect the partner you requesting a build for.

@@ Line 1: / Line 1: @@
-= Version Control =
+== Overview ==
-Mozilla keeps all of our partner repack configuration files under version control in [http://mercurial.selenic.com/ Mercurial (hg)].
-If you are unfamiliar with hg, Mozilla has some good dev resources for getting started:
+This document outlines the high level policy for Firefox custom bundles, applicable to all custom distributions of Firefox produced by Mozilla for partners.  Some of these requirements may be in conflict with existing written agreements, otherwise all existing distributions are expected to come into compliance with these requirements as soon as possible, and no later than June 30, 2015.  Some requirements will come into place over the first half of 2015, in order to allow time for any required changes to products or processes.
-* [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]
+For more information on becoming a Mozilla distribution partner, please refer to Becoming a Mozilla Distribution Partner.
-The partner-repacks repository (repo) is publicly available here: https://hg.mozilla.org/build/partner-repacks
+== Review Process and Timelines ==
-= Creating a patch =
+* Changes to custom configurations must be submitted no later than three weeks prior to the next regularly scheduled release, in order to be included in custom builds for that release.
-This section assumes that you are already familiar with the basics of hg.
+** After this time, only significant bug fix changes will be considered for that release.
+* Beta builds are produced twice weekly, and upon approval reviewers will advise as to the next set of builds which will contain the approved changes.
+* Release candidate builds will generally be available one week prior to the target release date.
+* Partners are not permitted to distribute custom builds prior to the official Mozilla release.
-Here is a generalized workflow:
+For an overview of the change submission process, please refer to the [[#Submitting_Changes|instructions below]].
-* clone the [https://hg.mozilla.org/build/partner-repacks partner-repacks repo]
-** if you already have the repo, run <code>hg pull && hg update -r default</code> instead
+== Build Identification ==
-* 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
+* Each unique configuration must be identified separately through a unique distribution ID.
-** make sure you run <code>hg add</code> to add new files, or <code>hg remove</code> if you are removing files
+* For each new custom distribution, partners must clearly identify the target market(s) and languages for the desired configuration, as well as any other reasonable information necessary to understand the scope for any potential distribution.
-* 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.:
+== Quality Requirements ==
- $ PARTNERNAME=aol
- $ hg export -g tip > repack_config_changes_for_$PARTNERNAME.diff
+* Mozilla will review and approve all changes to custom configuration.  Mozilla does not do formal Quality Assurance testing on custom bundles.  Distributors are expected to verify that all of their customizations are working as intended in the provided builds.
+== Preferences ==
+* All preference changes not explicitly required under existing agreements must be approved by Mozilla.
+* No preference changes will be permitted that negatively impact the security or user experience of end users.
+* Except where expressly covered by the distribution agreement, search default changes shall not be approved.
+== Bookmarks ==
+* Bookmarks must be clearly labelled, and should link only to relevant content from the partner in question.
+== Add-ons ==
-== Why create a patch? ==
+''Effective as of Firefox 39''
-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>.
+All bundled add-ons to be included with a custom distribution must already be signed in accordance with Mozilla's add-on signing policy.  This will require that all bundled add-ons have passed full review through the AMO review process, whether that add-on is or is not distributed on AMO itself.
-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.
+The process for submitting add-ons that are not to be hosted on AMO will be announced in the near future, and should be live in May 2015. If an add-on is already hosted on AMO at that time, signing will happen automatically.  Distribution partners will have priority for reviews, please contact Partner Support for more details.
-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.
+== Revenue-impacting Changes ==
-= Submitting a patch =
+''Effective as of Firefox 38''
-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].
+Firefox has a number of features that have revenue-bearing components, generally in the form of partnerships or paid placements.  These features include Search, Tiles, and other potential features. Except where otherwise agreed under a formal custom distribution agreement, no changes shall be permitted that negatively impact the revenue potential of these features.  This includes changes that would be otherwise permitted within the scope of an add-on under the AMO policy.
-To expedite the bug filing process, I've created a template that partners can use to quickly file bugs under the correct product & component:
+== Submitting Changes ==
-* Product: Release Engineering, Component: "Releases: Custom Builds"
-* 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]
+=== Version Control ===
+Mozilla keeps all of our partner repack configuration files under version control in [https://github.com/ GitHub].
-Please remember to change $PARTNERNAME in the bug summary to reflect the partner you are submitting the config change for.
+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 GitHub.
-Add your exported diff of changes from hg as an attachment to the bug.
+Here is a generalized workflow:
+* fork the repository
+* create a patch
+* submit a pull request
-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].
+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.
-== Why use Bugzilla? ==
+To expedite the bug filing process, I've created a template that partners can use to quickly file bugs under the correct product & component:
-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.
+* Product: Release Engineering, Component: "Releases: Custom Builds"
+* 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]
-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.
+Please remember to change $PARTNERNAME in the bug summary to reflect the partner you requesting a build for.