ReleaseEngineering/How To/Handle A New Repository Request

Document Status	Last Reviewed
DRAFT	not ready for review

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:

1. full path to repository
2. commit level required to access repository
3. list of hooks that should be enabled
4. 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:

1. reassign the bug to component "Server Operations: Developer Services" requesting creation of the 3 (b2g: 1) repositories per locale, with the indicated access level, hooks, and mxr indexing (b2g: no mxr)
2. 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):

1. negotiate details with the dev team, but ensure the top directory is appropriate for releng mapping of repositories
2. file new bugs for any changes needed to support the repository
3. if no post-repository-creation steps are needed, reassign bug to "Server Operations: Developer Tools"
4. 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:

1. Escalate internally to determine level of release engineering support and general approach
2. 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:

1. 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.
2. reassign the request to component "Server Operations: Developer Tools"