MozillaWiki

RapidRelease

Revision as of 06:29, 1 April 2011 by Sayrer (talk | contribs) (copy editing)

Overview

Mozilla's plan is is to introduce much faster Firefox releases in order to provide more frequent improvements to users without disrupting longer term work.

This page points you to canonical information sources and current discussions where possible. If something is not finalized or started, owners are attempted to be listed. Read the following two documents first.

A draft summarizing the process is at: http://mozilla.github.com/process-releases/draft/development_overview/

A detailed process plan is being worked on by Christian and Sheila: http://mozilla.github.com/process-releases/draft/development_specifics/

Both are available in git so you can track changes: http://mozilla.github.com/process-releases/

Please direct discussion to the dev-planning mailing list: https://lists.mozilla.org/listinfo/dev-planning

Firefox 5 State

This is a list of actions that have been taken for FF5. Differences or potential differences due to ongoing discussions in future releases (post FF6 and beyond) will be noted.

mozilla-central

  • open for a 3 week period starting March 23 and ending April 12
    • NOTE: will 6 weeks in future releases
  • build sheriffing will focus on high gain, low risk items
    • see bsmedberg for questions
    • tree is closed when there is no sheriff
  • cedar is being run by Ehsan and is being used for checking-needed bugs

Version and User Agent

  • version number of 2.2a1pre/4.2a1pre
    • NOTE: Versioning under discussion
  • historical user agent string, ie
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.2a1pre) Gecko/20110330 Firefox/4.2a1pre
    • NOTE: Changes to user agent string under discussion

Bugzilla

  • mozilla2.2 target milestone for mozilla-central
    • NOTE: May change do to version number changes and/or triage process changes that are in discussion

Nightlies & Beta Channel

  • Nightlies stay on mozilla-central
  • Beta users stay on beta channel with no updates
    • NOTE: This will change either with progress on 4.0.1 or with channel discussion finishing

Current Discussions

This section documents key discussion points and proposals that are in progress or need to happen. It also notes anything unclear. Where possible, it documents owners who need to give input and/or drive the item to conclusion.

Development Specifics [legneato]

These are highlights of discussion going on in the dev-planning mailing list related to Christian's document at: http://mozilla.github.com/process-releases/draft/development_specifics/

Versioning

  • Must be consistent and predictable
    • Teams outside of engineering must know what is coming - metrics, SUMO, socorro,input
  • 3 versioning proposals
  • Need to ensure that teams such as metrics, SUMO, socorro, input can access detailed version info
    • js property, whitelist, user prompt (like geolocation)
  • versioning in project branches and local builds should have a sane default that doesn't conflict with automated build system numbering

Gecko Versioning

  • Proposed to sync this with Firefox version
    • Need to check with other consumers like Thunderbird about this
  • Current system supports detaching Firefox from platform releases, which is called out in Christian's doc

User Agent

  • Proposed to stabilize the version in the User Agent - for instance even in experimental it would say Firefox/5.0

L10N and I18N [legneato, smooney, axel, choffman, christian]

Builds

  • Are beta channel builds signed?

Security Updates [chofmann, dveditz, legneato]

  • the priority is last release branch
    • we fix on all branches
  • needs follow up on shadow repo possibilities

Release Updates

  • Current proposal is no 5.0.x, 6.0.x etc updates other than chemspills
    • based off the 6 week m-c pull cycle
    • each release can be marketed in a different way
  • Needs re-evaluation at FF6 to mozilla-experimental pull

Meetings

  • How does current meeting structure need to change for the new process?
    • Where and when do go/no-go decisions get made
    • Where and when is blocker triage done

Channel Distribution [smooney, rs, limi]

This is about how to divide up beta users into multiple testing channels for -experimental and -beta. There are decisions about how to divide up the user base and there are supporting code changes to make this happen.

  • Better discoverability of version information for SUMO, Input, Bugzilla as we break these ups

Repository Mechanics [joduinn, legneato]

Branch Naming

How to name branches, particularly release branches.

Merging

How to do the merge to downstream branches from a mechanical standpoint.

  • Do not delete experimental, merge from m-c
  • track to see how much of a problem we get with backouts/preffing off
  • the first merges will be manageable

Chemspill

How to do chemspills on releases.

  • Still wide open.

Blocker Tracking

Add On Compatibility [fligtar, jorge]

QA [rob, matt]

  • as QA gets inserted, need clear suspension/resumption criteria for conflicts like chemspill vs release
  • beta feedback is a big chunk of is it shippable feedback, and we are reducing it

Feature Planning [dria]

Because of timelines, this process will not impact Firefox 5 very much, but should be come much more important in FF6 and full formed for FF7.

Development Best Practices [engineering teams]

Features must be "ready" for landing on mozilla-central, in general this is up to module owners, sheriffs and teams, but building a set of best practices would be ideal.

Platform Consumer Outreach [jpr, kev]

  • Linux distribution that need to be prepared for speed of shipping
  • ATV outreach (screen readers, etc)

Cheat Sheet

This is a list of key items that were discussed and are now at consensus or near-consensus. A Cliff Notes if you will of the key changes in the development process - refer to the documents in the Overview for all the details

Mini-Glossary

  • Stabilization is the process of backing out and preff-ing off features and changes
  • Downstream Repository is the repository from which an antecedent or Upstream Repository is merged to, for instance mozilla-experimental is the downstream repository for mozilla-central in the current

Repositories

  • mozilla-central merges to mozilla-experimental every 6 weeks
  • Stabilization occurs after the pull to the downstream branch
  • A bug fix for any repository (for instance mozilla-beta) lands in all upstream repositories at same time as well

Feature & Major Change Policy

  • All features and major changes should be kill switched and/or easy to back out
  • Where possible forward proofing should be employed (config, data)
    • at most backward and forward one version ie experimental vs mozilla-central
  • developer takes the pain of backing out!

4.0.x and Previous Releases

This section clarifies some questions that have come up about the relationship between Firefox 4 and older and Firefox 5.

  • 5.0 and newer processes will not be "backported" onto 4.0.x and older releases
  • there will be 4.0.x releases and chemspill handling
    • branch team is taking over for 4.0.1
  • there will be 3.6.x and 3.5.x releases and chemspill handling
Retrieved from "https://wiki.mozilla.org/index.php?title=RapidRelease&oldid=295874"