LargeScaleMaintenance

Bzr Branch Layout

Extension Name

The extension name for branches should match the (prospective) extension source package name; this document suggest to not use a mozilla-, firefox- etc. prefix in the package name, but rather include that info in the short summary of the package.

fta: extension-name should have a predefined format for consistency (asac: done)

Branch Names

  • $EXTENSION_NAME.upstream - upstream branch in which new .xpis released upstream (on addons.mozilla.org) get imported.
  • $EXTENSION_NAME.ubuntu - packaging release branch that tracks ubuntu development release.
  • $EXTENSION_NAME.ubuntu.staging - packaging release branch that receives auto-merges on .upstream commits.
  • $EXTENSION_NAME.ubuntu.$RELEASE - packaging release branch tracking stable releases (what was initially released and afterwards, what got uploaded to -proposed, -updates); for example RELEASE could be hardy, gutsy, feisty, etc. or hardy-backports, gutsy-backports and so on.
  • $EXTENSION_NAME.ubuntu.$RELEASE.staging - branch in which new .upstream commits automatically get merged in.
  • autoupdater.data - a branch that holds configuration for the auto bot (such as a list of extensions that get auto synched)

Branch Permissions

The following branch permissions appear to match the quality requirements for the branches introduced above:

  • .upstream branch - restricted area only writable by mozillateam members
  • .ubuntu and .ubuntu.$RELEASE branch - restricted area writable for devs that can upload to $RELEASE (e.g. ubuntu-dev for universe packages)
  • .ubuntu.$RELEASE.staging branch - restricted area writable only by mozilla-extension-dev members
  • autoupdater.data - restricted to be edited by mozillateam members

Procedures

Setting up new extensions

Adding new .upstream branches to the auto updater is a manual step requiring that a mozillateam member update the autoupdater.data branch. To request a new upstream branch the extension QA contact has to file a bug against firefox-extensions project in launchpad. When requesting a new extension to be synched, the requestee should provide the following information:

  • Extension name
  • Source package name - the suggested name for the Ubuntu package. Look at the "Extension name" paragraph on this page.
  • Repo - indicates whether the extension is in the repository
  • Extension developer contact

  • addons.mozilla.org ID - the extension ID on the addons.mozilla.org. In example, for extension with the link https://addons.mozilla.org/en-US/firefox/addon/'''1, the ID is 1.

  • License (if available)
  • Compatibility - shows if the extension is compatible with the current Firefox version. Set to "yes" if it is fully compatible, "bump" if it is compatible, but with compatibility check disabled, "no" if it is broken.
  • Status - indicates the current status in extension packaging. Should be set to "open" for suggested new extensions.
  • Ubuntu QA contact - if the requestee is planning to package and maintain this extension in Ubuntu, this field should point to his e-mail address.

A mozillateam member will review those request on a regular basis and add extensions to the autoupdater.data branch.

Optional/Later: The bot might publish warnings about extensions that are not properly documented in wiki page if possible.

Getting the Packaging Started

The auto updater will automatically try to create an initial packaging for new branches for the .ubuntu.staging. branch. However, it shouldn't create .ubuntu.$RELEASE.staging branches until a .ubuntu.$RELEASE branch was manually set up.

Reviewing/Releasing from the .staging branch

The auto updater creates a list of extensions that have new versions on the .staging branch, which indicates that a mozilla-extensions-dev member (preferably the QA Contact) should review its state and sign it off. Once the sign off is done, a ~ubuntu-dev member will push the .staging branch to the release branch which is hosted in ~ubuntu-(core-)dev realm - depending on whether an extension is released to universe (ubuntu-dev) or main (ubuntu-core-dev).

The sign off is done by submitting a bug, attaching the .staging branch to it and suggesting the branch for merge on the release branch (using LP). The sign-off must state the commit id it is referring to.

Component & Use-Cases

Auto Updater

  • auto import new upstream releases. This document suggests to first implement the auto sync for AMO .xpis and later define how VCS imports could be implemented effectively.
  • auto merge new upstream imports to .staging branches

Task Helper

  • identify .staging branches that need to be reviewed/signed-off
  • identify .upstream/.ubuntu.XX branch combinations that need a manual conflict resolution
  • identify .staging branches that need to be redone by the auto bot (the autoupdater should use this script to identify those and redo the .staging branch); this happens in the corner case where the .ubuntu branch was manually updated _after_ the .staging branch was merged, but _before_ the .staging branch was signed-off/pushed to the release branch

Release Helper

  • build test package from .staging branch; this helps Ubuntu QA members and ubuntu-devs to test packages during review/sign-off
  • allow Ubuntu QA members to sign off .staging revisions
  • allow ubuntu-dev/ubuntu-core-dev members to easily release .staging branches. this would automatically push the .staging branch to the appropriate release branch and and build the source packages from it

CategoryMozillaTeam

MozillaTeam/Extensions/LargeScaleMaintenance (last edited 2008-08-06 16:14:27 by localhost)