ReleaseEngineering/How To/Handle A New Repository Request
Contents
Summary
This page lists the detailed process that RelEng uses to handle requests for new repositories hosted inside mozilla.org. The process overview is at ReleaseEngineering/RepositoryCreationRequest
The intended audience for this document are members of the release engineering team, others may find some of the terminology opaque :)
Common Processing
All requests must contain the following information at a minimum:
- enough information to determine the support category of the repository.
- the affiliation of the requester or the proposed name may be sufficient
- The categorization process may supply the full repository name and/or commit level required
- proposed name of the repo (no more top level repositories can be created)
- commit level required
Once that information has been added to the bug, the processing continues based on the category.
At some point, all approved repositories will be created by the developer tools team in IT. At a minimum, the following information must be provided in all such requests:
- full path to repository
- commit level required to access repository
- list of hooks that should be enabled (from this list)
- a description of the purpose of each repository (one liner for display by the web interfaces). This is optional, but recommended.
Categorizing
The following table lists the tests to determine category. The first match wins.
| Test | Notes | ||||||
|---|---|---|---|---|---|---|---|
| Is repo is a new locale for firefox product? | If so, process according to #new_ff_locale | Will repo be used by any of the FF or TB CI machinery? | If so, process according to #ff_tb_ci | Will repot require support from Release Engineering? | If so, process as #rel_eng_supported | otherwise | Process as #no_rel_eng_support |
Category Specific Processing
New FF Locale
Awaiting confirmation on b2g changes - for now the assumptions are in parenthesis.
These are "auto approved" on hg.m.o for repositories under "releases/l10n/" (b2g under: "/gaia-l10n/").
Steps (details from l10n side are at L10n:Bugogram#hg_repo:
- reassign the bug to component "Server Operations: Developer Services" requesting creation of the repositories per locale, with the indicated access level, hooks, as follows:
- For Firefox locale: this means creating repos in each of /releases/l10n/mozilla-aurora, /releases/l10n/mozilla-beta, /releases/l10n/mozilla-release, with mxr indexing.
- For B2G locale: this means creating one repo in /gaia-l10n, with 'no' mxr indexing
- Notify release that a new locale is on the horizon
Done
New repo used by build farm
These are repositories that are (or soon will be) used by the build farm, even if they don't comprise shipping code. These need to be vetted for naming consistent with other repos, processes, etc. These requests may be the first we hear of a project, and represents the chance to engage early to smooth eventual integration issues.
Steps (roughly):
- negotiate details with the dev team, but ensure the top directory is appropriate for releng mapping of repositories
- file new bugs for any changes needed to support the repository
- if no post-repository-creation steps are needed, reassign bug to Product: "mozilla.org", Component: "Server Operations: Developer Services"
- otherwise, open a new bug for the repository creation, and all supporting activities releng needs to do
Supported by Release Engineering
These are repositories which the requester believes will eventually be handled in some way by Release Engineering, but don't fit the existing machinery. (For example, a project that doesn't use hg for it's repository of record.)
These will take significant effort to support, and are more fuzzy. There may be negotiations that change assumptions about this is an appropriate repository for release engineering to support.
Steps:
- Escalate internally to determine level of release engineering support and general approach
- Handle as #ff_tb_ci or #no_rel_eng_support as appropriate
Not supported by Release Engineering
Many other groups use the mozilla.org repositories - we get out of their way as fast as we can.
Steps:
- ensure repository name is in a non-RelEng namespace (top level directory)
- ssot to be linked later; currently releng "owns" (null), releases, integration, projects, and build.
- reassign the request to Product: "mozilla.org", Component: "Server Operations: Developer Services"
General Notes
With the presence of git.m.o, there are now more choices than ever. Below are the practices in effect as of 2013-01-24
In general, hg remains the repository of record for all Mozilla work processed by Release Engineering. Some exceptions are noted below.
Until some general policies are worked out, the repos available via both repository types are restricted to those associated with FFOS (nee b2g).
FFOS
FFOS is released via source tagging of repositories on git.m.o. This means hg repositories need to support a git view as follows:
- Gecko code base (mercurial mozilla-* repos) for source released to partners is read-only in git.m.o/releases/gecko.git, using branches that are FFOS based, not Firefox/Fennec based (i.e. they don't ride the browser trains)
- Gaia code base (git.m.o:release/gaia.git, with committable master repo at github:mozilla-b2g/gaia.git). HG read only mirrors of this are solely for use of the internal release engineering tooling. (No plan yet for localizers or others preferring to use hg to view gaia sources as of 2012-01-24.)
- Localizations for FFOS. (Only the locales actively being shipped to partners are mirrored as of 2013-01-24.) Only one repo is used, with internal branches (no such branches as of 2013-01-24):
- Gaia localizations (hg.m.o/gaia-l10n/* repos) are mirrored (read only) to git.m.o:releases/l10n/<locale>/gaia.git.
- Gecko localizations (hg.m.o/releases/l10n/<train>/<locale>) are mirrored (read only) to git.m.o:releases/l10n/<locale>/gecko.git. ('mozilla-beta' is the only branch as of 2013-01-24)
