Pocket is built into the Firefox browser, allowing you to save a variety of content (such as blogs, news sources, web pages and videos) to one place with the click of a button so that you can access it later from any device. To get started, sign up for a free Pocket account. If you use Firefox, Pocket is already built-in! Get Started with Pocket for Firefox We offer extensions for Google Chrome, Safari, Opera, Microsoft Edge, and most Chromium-based browsers. Save and discover the best stories from across the web. Get protection beyond your browser, on all your devices. Product Promise. Learn how each Firefox product protects and respects your data. Sign up for new accounts without handing over your email address. Firefox Private Network (beta).

1. Firefox Pocket Login
2. What Is Firefox Pocket
3. Firefox Pocket Reddit
4. Firefox Pocket Review

Estimated read time: 15min

Introduction¶

The purpose of this document is to provide a high level understanding ofhow Mozilla ships Firefox. With the intention of helping new Mozillians(and those who would like a refresher) understand the basics of ourrelease process, tools, common terms, and mechanisms employed inshipping Firefox to our users. Often this document will introduce aconcept, explain how it fits into the process, and then provide a linkto learn more if interested.

Note

This does not contain an overview of how weship Fenix (Our next gen Android browser) asthat product is largely uncoupled from how we ship to desktop and theprocess we’ve historically followed.

Repositories & Channels¶

Shipping Firefox follows a software release train model along 3 primary coderepositories; mozilla-central (aka “m-c”),mozilla-beta, and mozilla-release. Each of these repositories areupdated within a defined cadence and built into one of our Firefoxproducts which are released through what is commonly referred to asChannels: Firefox Nightly, Firefox Beta, and FirefoxRelease.

Firefox Nightly offers access to the latest cutting edge featuresstill under active development. Released every 12 hours with all thechanges that have landed on mozilla-central.

Every 4 weeks, wemerge the code from mozilla-central to ourmozilla-beta branch. New code or Features can be added to mozilla-betaoutside of this 4 week cadence but will be required to land inmozilla-central and then be uplifted intomozilla-beta.

Firefox Beta is for developers and early adopters who want to seeand test what’s coming next in Firefox. We release a new Beta versionthree times a week.

Note

The first and second beta builds of a new cycle are shipped to asubset of our Beta population. The full Beta population gets updatedstarting with Beta 3 only.*

Each Beta cycle lasts a total of 4 weeks where a final build isvalidated by our QA and tagged for release into the mozilla-releasebranch.

Note

Firefox Developer Editionis a separate product based onthe mozilla-beta repo and is specifically tailored for Web Developers.

Firefox Release is released every 4 weeks and is the final productof our Beta cycle. As our primary product shipping to hundreds ofmillions of users, interim updates andride-alongs are only shipped to Release ifthey contain dot release drivers.

Note

Firefox ESR (Extended Support Release)is a separateproduct intended for Enterprise use. Major updates are rolled out 1-2times per year to maintain stability and predictability. ESR alsocontains a number of policy options not available in the standardFirefox Release. Minor updates are shipped in sync with the FirefoxRelease schedule for security and stability fixes only.

Further Reading/Useful links:

Landing Code and Shipping Features¶

Mozillians (those employed by MoCo and the broader community) land lotsof code in the Mozilla repositories: fixes, enhancements, compatibility,new features, etc. and is managed by Mercurial (akahg). All new code is tracked in Bugzilla, reviewedin Phabricator, and then checked into themozilla-central repository using Lando.

Note

Some teams use GitHub <github> during developmentbut will still be required to use Phabricator (tracked in Bugzilla) tocheck their code into the mozilla-central hg repository.

The standard process for code to be delivered to our users is by ‘ridingthe trains’, meaning that it’s landed in mozilla-central where it waitsfor the next Beta cycle to begin. After merging to Beta the code willstabilize over a 4 week period (along with everything else that mergedfrom mozilla-central). At the end of the beta cycle a release candidate(RC) build will be generated, tested thoroughly, andeventually become the next version of Firefox.

Further Reading/Useful links:

• Firefox Trello (Distilledlist of critical features riding the trains)

An exception to this process…¶

Not all code can simply wait for the normal train model to be includedin a Firefox build. There are a variety of reasons for this; criticalfixes, security concerns, stabilizing a feature that’s already in Beta,shipping high priority features faster, and so on.

In these situations an uplift can be requested to take a recent landingin mozilla-central and merge specific bits to another repository outsidethe standard train model. After the request is made within Bugzilla,Release Management <release management> will assess the potential riskand will make a decision on whether it’s accepted.

Further Reading/Useful links:

Ensuring build stability¶

Throughout the process of landing code in mozilla-central to riding thetrains to Firefox Release, there are many milestones and qualitycheckpoints from a variety of teams. This process is designed to ensurea quality and compelling product will be consistently delivered to ourusers with each new version. See below for a distilled list of thosemilestones.

The Release Management team (aka “Relman”) monitors and enforces thisprocess to protect the stability of Firefox. Each member of Relmanrotates through end-to-end ownership of a given releasecycle. The Relman owner of a cycle will focus on theoverall release, blocker bugs, risks, backout rates, stability/crashreports, etc. Go here for a complete overview of the Relman ReleaseProcessChecklist.

Note

While Relman will continually monitor the overall health of eachRelease it is the responsibility of the engineering organization toensure the code they are landing is of high quality and the potentialrisks are understood. Every Release has an assigned RegressionEngineering Owner (REO) to ensure a decision is madeabout each regression reported in the release.*

Further Reading/Useful links:

Enabling/Disabling code (Prefs)¶

Within Firefox we allow the ability to Enable/Disable bits of code orentire features using Preferences <preferences>. There are manyreasons why this is useful. Here are some examples:

• Continual development over multiple release cycles without exposingpartially completed features to our users

• Provide the ability to quickly disable a feature if there is aproblem found during the release process

• Control features which are experimental or not ready to be shown to aspecific channel population (e.g. enabled for Beta but disabled forRelease)

• A/B testing via telemetry experiments

Note

Normandy Pref Rollout is a feature thatallows Mozilla to change the state of a preference for a targeted set ofusers, without deploying an update to Firefox. This is especially usefulwhen conducting experiments or a gradual rollout of high risk featuresto our Release population.

Further Reading/Useful links:

Release & Feature QA¶

Release QA is performed regularly and throughout the Release Cycle.Organized in two-week sprints its primary goals are:

Firefox Pocket Login

• Qualifying builds for release

• Feature testing

• Product Integrity requests

• Bug work

• Community engagement

Features that can have significant impact and/or pose risk to the codebase should be nominated for QA support by the featureowner in its intended release. This process is kickedoff by filing a Product Integrity team requestPI request. These are due by the end of week 2of the Nightly cycle.

Note

Manual QA testing is only required for features as they gothrough the Beta cycle. Nightly Feature testing is always optional.

Further Reading/Useful links:

Experiments¶

As we deliver new features to our users we continually ask ourselvesabout the potential impacts, both positive and negative. In many newfeatures we will run an experiment to gather data around these impacts.A simple definition of an experiment is a way to measure how a change toour product affects how people use it.

An experiment has three parts:

1. A new feature that can be selectively enabled

2. A group of users to test the new feature

3. Telemetry to measure how people interact with the new feature

Experiments are managed by an in-house tool calledExperimenter.

Further Reading/Useful links:

• Requesting a newExperiment(Follow the ‘help’ links to learn more)

Definitions¶

Bugzilla - Web-based general purpose bug tracking system and testingtool

Channel - Development channels producing concurrent releases ofFirefox for Windows, Mac, Linux, and Android

Dot Release Drivers - Issues/Fixes that are significant enough towarrant a minor dot release to the Firefox Release Channel. Usually tofix a stability (top-crash) or Security (Chemspill) issue.

Feature Owner - The person who is ultimately responsible fordeveloping a high quality feature. This is typically an EngineeringManager or Product Manager.

Fenix - Also known as Firefox Preview is an all-new browser forAndroid based on GeckoView and Android Components

Github - Web-based version control and collaboration platform forsoftware developers

Landing - A general term used for when code is merged into aparticular source code repository

What Is Firefox Pocket

Lando - Automated code lander for Mozilla. It is integrated withour Phabricator instanceand can be used to land revisions to various repositories.

Mercurial - A source-code management tool which allows users to keeptrack of changes to the source code locally and share their changes withothers

Merge - General term used to describe the process of integrating andreconciling file changes within the mozilla repositories

Normandy - Normandy is a collection of servers, workflows, andFirefox components that enables Mozilla to remotely control Firefoxclients in the wild based on precise criteria

Phabricator - Mozilla’s instance of the web-based softwaredevelopment collaboration tool suite. Read more about Phabricator as aproduct.

PI Request - Short for Product Integrity Request is a formsubmission request that’s used to engage the PI team for a variety ofservices. Most commonly used to request Feature QA it can also be usedfor Security, Fuzzing, Performance, and many other services.

Preferences - A preference is any value or defined behavior that canbe set (e.g. enabled or disabled). Preference changes via user interfaceusually take effect immediately. The values are saved to the user’sFirefox profile on disk (in prefs.js).

Product Integrity - The Product Integrity team is responsible forensuring product quality and release consistency by testing features,validating builds, and managing the overall release process. Inaddition, PI provides various engineering support functions such assheriffing, bug triage and investigation.

Release Candidate - Beta version with potential to be a finalproduct, which is ready to release unless significant bugs emerge.

Release Cycle - The sum of stages of development and maturity forthe Firefox Release Product.

Regression Engineering Owner - A partner for release managementassigned to each release. They both keep a mental state of how we aredoing and ensure a decision is made about each regression reported inthe release

Release Management - Team primarily responsible for the process ofmanaging, planning, scheduling and controlling a software build throughdifferent stages and environments

Repository - a collection of stored data from existing databasesmerged into one so that it may be shared, analyzed or updated throughoutan organization

Firefox Pocket Reddit

Ride Alongs - Bug fixes that are impacting release users but notconsidered severe enough to ship without an identified dot releasedriver.

Firefox Pocket Review

Telemetry - Firefox measures and collects non-personal information,such as performance, hardware, usage and customizations. Thisinformation is used by Mozilla to improve Firefox.

Train model - a form of software release schedule in which a numberof distinct series of versioned software releases are released as anumber of different “trains” on a regular schedule.

Uplift - the action of taking parts from a newer version of asoftware system (mozilla-central or mozilla-beta) and porting them to anolder version of the same software (mozilla-beta or mozilla-release)