tl;dr: Follow the Requestor Actions below

Process for Creating New Repositories

What (scope)

This process covers all new requests for community visible repositories to be hosted on MoCo machinery, regardless of repository type (hg, git, svn, cvs).

• Not covered: - special internal repositories, such as those used by IT.
• Not Significantly Impacted: - repositories used by groups not needing RelEng support.

Why (benefits)

The world of MoCo repositories is getting more complex with the addition of git support, and requires more coordination between RelEng and IT. This process provides that. In addition, repository creation is the first tangible event that brings the project in contact with technical support groups (RelEng/IT). The restructuring of the existing process will also improve communication with the technical groups, providing them the opportunity to provide better service to the project with minimal disruptions.

How (mechanics)

The approach gives a single process for all requests, reducing confusion for both requester and the implementer. When there are options or decisions needed, they are grouped to minimize the number of touch points with the customer.

Requester's Actions:

FxOS No Longer needs to mirror to repos git.mozilla.org!!!! This was only needed with older release build machinery, and no FxOS project is still using the old machinery. \o/

Mirroring (non FxOS): If you are requesting a new mirror of an existing repository to either hg.mozilla.org or git.mozilla.org, we just need the UPSTREAM_URL and which BUG this blocks. (Path names on *.m.o servers will be assigned.) Use Mirror template.

Other cases: File a bug including:

• what commit access level is required (not needed for mirror only repositories)
• the purpose of the repository
• which product(s) it will ship as part of (if any)
• Answer any questions that come up
• Wait for path to repository to be provided with the resolution of the bug.

RelEng Actions:

Below is a summary - RelEng team members should use the actual instructions

1. Ensure request is complete, including determination of need for RelEng services over the life of the project. Continue....
2. If no RelEng services are required, annotate the bug to that effect, and forward to IT* for implementation. Requester notified when IT creates repository and resolves bug as fixed. DONE
3. If RelEng services are required, RelEng will file related tickets for both short term and long term service needs. One of those tickets will be the IT* bug for repository creation. Continue....
4. When RelEng is notified of repository availability, perform any remaining RelEng service setup. Notify requester by resolving bug as fixed when everything is ready. DONE

* IT component to use is: Server Operations: Developer Services

Note: the assumption is that only RelEng coordination is needed. If other groups wish approval, coordination, they would be looped in here.

IT Actions:

1. Verify that request has been processed by RelEng. If not, reroute request to RelEng. DONE
2. Create repository with appropriate permissions. Do whatever else is needed (backup jobs, etc.). Continue....
3. Resolve ticket as fixed. DONE

Note: the assumption is that all needed information is already in the ticket. If not, IT works with RelEng to obtain the additional information. IT's expectation should be that RelEng will incorporate those questions into their process, so such exceptions only happen once.

Behind the Scenes

If the above looks simple, great! The complexity can possibly come at two points, both of which are masked from the requester. IT, in step 2, may hit thresholds which require rebalancing of storage, requests for additional storage, and all kinds of IT things. RelEng, in step 3, may discover requests for testing that will require additional and/or new hardware. Or requests for services that are not yet provided.

In both cases, the full resolution may require months of equipment lead time, tool development and deployment, and other behind the scenes activities. This process ensure such planning starts happening no later than the repository request event.