MozillaWiki

Firefox/Go Faster/System Add-ons/Process

< Firefox‎ | Go Faster
Revision as of 18:31, 27 October 2016 by Ckprice (talk | contribs) (Init)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

BEGIN DRAFTNOTES

In Q3 we saw the major use case for system add-ons shift to hotfix type things. We also have much more example bugs and emails to pull from. So these updates will focus on incorporating those examples, and mapping these documents to how things actually happen.

I also moved this into a "System Add-On" sub directory since it focuses just on that part of the process.

END DRAFTNOTES

Overview

This document will have everything you need to deploy a system add-on.

This documentation leans heavier on a process of updates/fixes to existing versions of Firefox. For larger, feature-based add-ons, code may be required to live on pre-release channels longer before it is approved to move to production.

Getting Started

Is this something appropriate for a system add-on?

You can view our documentation here: https://wiki.mozilla.org/Firefox/Go_Faster/When_To_Use_System_Add-ons

The major use cases for system add-ons is to roll out a vetted and QA'd feature or fix off of the standard release trains.

Where can I find existing examples of system add-ons?

Go Faster System Add-ons will have WHITEBOARD=[go-faster-system-addon]

Examples of a simple pref flip

Examples of more complex feature add-ons

More questions?

You can always cold-call gofaster@mozilla.org, or visit us in #gofaster to chat!

Tracking Bug and Intent to Implement

Tracking Bug

  • Every system add-on should have a tracking bug (see Getting Started for examples).
  • Product/Component is dependent on the add-on.
  • Set the WHITEBOARD=[go-faster-system-addon] to allow the Go Faster team to track status.

Intent to Implement

  • Intent to Implement emails are especially helpful for larger add-ons.
  • This allows any potential interested parties to comment on the validity and testing requirements for the system add-on.
  • More simple pref flip add-ons may not require an Intent to Implement email.
  • A good example: https://mail.mozilla.org/pipermail/gofaster/2016-September/000434.html

The Intent to Implement email should have

Field Example
Tracking bug see Getting Started for samples
References Wiki page, or repository
Overview What does the add-on do? What problem is it trying to fix?
Timeline What is the rough timeline (and channel) for delivery?
mailto: release-drivers@mozilla.org; gofaster@mozilla.org

This early notification is also important for extremely timely system add-ons, and will prepare the teams for a fast turnaround.

Responsibility: add-on developer/owner; interested parties to review

QA and Code Review

QA and code review of your XPI is the responsibility of the add-on developer/owner.

This can be done in a bug or GitHub issue. The end result is an agreement from the responsible QA party that the add-on is ready for release.

Once the add-on is approved, QA approval should be posted to the bug/issue, and/or sent through release-drivers@mozilla.org and gofaster@mozilla.org.

A signed XPI should also be included in the bug.

Responsibility: add-on developer/owner; code reviewer; QA

Intent to Ship and RelMan Approval

Intent to Ship

Once the add-on has been reviewed by QA, an Intent to Ship email should be sent.

Please expect a lead time of at least 3 business days between the email being sent, and the add-on released into production. Holidays and work weeks will effect scheduling.

The Intent to Ship email should have

Field Example
Tracking bug see Getting Started for samples
System add-on comment linking to signed XPI
Committed to mozilla-release Was this committed to mozilla-release? If so, include commit ID
Verification Link to comment with QA verification
User Impact What are we fixing? What is the risk of this not going out?
Timeline When does this need to go live?
Targeting Version e.g. 49.0, 49.0.2, 50.*
Additional target rules Are we targeting a specific OS, build ID, distribution, etc
mailto: release-drivers@mozilla.org; gofaster@mozilla.org

Example: https://mail.mozilla.org/pipermail/gofaster/2016-October/000507.html

Release Management Approval

The driver of the current release should Reply All to the Intent to Ship email with approval for release.

Responsibility: add-on developer; release management

Deployed to Test Channel

After RelMan has approved the add-on for shipping, the Go Faster Team will update the test channel (`release-sysaddon`) in Balrog with the relevant rules and send out an email and post to the tracking bug.

These Deployed to Test Channel emails should include

Field Example
Versions affected e.g. 49.0, 50.*
System add-on information The ID's and versions of the system add-on(s)
Balrog details Rules and releases modified in Balrog
mailto: release-drivers@mozilla.org; gofaster@mozilla.org

Examples

Responsibility: Go Faster Team

Verification of Test Channel

The purpose of this step is to receive verification that the add-on is being deployed correctly on the test channel (`release-sysaddon`).

This should be done by another Go Faster Team member, or external QA.

Notes on how best to verify system add-ons on the test channel can be found here: https://wiki.mozilla.org/Firefox/Go_Faster/Releasing_an_add-on_mechanics#Verifying_Balrog

Once the test channel has been verified, a Reply All should be sent to the "Deployed to Test Channel" email.

Responsibility: Go Faster Team peer review; QA

Push Release and Rules to Production

Once the test channel is verified, the Go Faster team will update Balrog to the release channel, and update the bugs.

Example: https://bugzilla.mozilla.org/show_bug.cgi?id=1312528#c19

Responsibility: Go Faster Team

Measurement

2016Q4 Goal is to track rollout of the add-on. See: https://wiki.mozilla.org/Firefox/Go_Faster/Measurement

Retrieved from "https://wiki.allizom.org/index.php?title=Firefox/Go_Faster/System_Add-ons/Process&oldid=1152900"