CloudServices/Github: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with "== GitHub for Cloud Services Engineers == Aside from some [https://hg.mozilla.org/services/ legacy projects] in mercurial, all of the code for the Cloud Services team lives i...")
 
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
== GitHub for Cloud Services Engineers ==


Aside from some [https://hg.mozilla.org/services/ legacy projects] in mercurial, all of the code for the Cloud Services team lives in [https://github.com GitHub].  There are over a thousand Mozilla-related repositories in total, but no over-arching corporate policy on How Mozilla Should Use GitHub, so it can easily get a bit confusing - this document exists to help you make some sense of it all.
Aside from some [https://hg.mozilla.org/services/ legacy projects] in mercurial, all of the code for the Cloud Services team lives in [https://github.com GitHub].  There are over a thousand Mozilla-related repositories on there in total, but no over-arching corporate policy on How Mozilla Should Use GitHub, so it can easily get a bit confusing - this document exists to help you make some sense of it all.


It's all guidelines, not actual rules.  Do what works, but please review the below as well as the top-level [[Github]] info page.
It's all guidelines, not actual rules.  Do what works, but please review the below as well as the top-level [[Github]] info page.


=== Organizations ===
== Organizations ==


Cloud Services code is spread across two github organisations:
Cloud Services code is spread across two github organisations:
Line 15: Line 14:


* Projects that are mostly infrastructure-related, or are heavily specific to Mozilla's internal needs, should go in "mozilla-services".  Examples include [https://github.com/mozilla-services/circus Circus] and [https://github.com/mozilla-services/heka Heka] as well as various puppet configuration repos.
* Projects that are mostly infrastructure-related, or are heavily specific to Mozilla's internal needs, should go in "mozilla-services".  Examples include [https://github.com/mozilla-services/circus Circus] and [https://github.com/mozilla-services/heka Heka] as well as various puppet configuration repos.
* Projects that will be of more general interest to the Mozilla community should go in "mozilla".  Examples include the [https://github.com/mozilla/persona Persona] and [https://github.com/mozilla/fxa-auth-server Firefox Accounts] application servers.
* Projects that will be of more general interest to the Mozilla community, or that are more clearly aligned with Mozilla's mission and brand, should go in "mozilla".  Examples include the [https://github.com/mozilla/persona Persona] and [https://github.com/mozilla/fxa-auth-server Firefox Accounts] application servers.


You will not have to look hard to find counter-examples to the above.  Don't fret.  Just do what you think is sensible.
You will not have to look hard to find counter-examples to the above.  Don't fret.  Just do what you think is sensible.


=== Teams and Permissions ===
== Teams and Permissions ==


=== Security ===
Access control to repositories in an organization is managed by ''teams''.  Please review the [https://help.github.com/articles/permission-levels-for-an-organization-repository Teams Permission Model] which is thankfully quite simple.
 
All Cloud Services Engineers should be members of the following teams:
 
* https://github.com/orgs/mozilla/teams/services
* https://github.com/orgs/mozilla-services/teams/cloudservices-engineers
 
If you're not a member (and getting a 404 when you visit the team page is a good indication that you're not) please contact an owner (see below) and they can fix it up.
 
We also have the following project-specific teams.  If you're working on these projects, make sure you're in the appropriate team:
 
* https://github.com/orgs/mozilla/teams/fxaccounts
* https://github.com/orgs/mozilla/teams/identity
* https://github.com/orgs/mozilla/teams/identity-owners
* https://github.com/orgs/mozilla/teams/services-admin
* https://github.com/orgs/mozilla/teams/svcops
 
* https://github.com/orgs/mozilla-services/teams/sagrada-devs
 
== Security ==


Make sure you have two-factor auth enabled on your account.  This goes double if you're an Owner.
Make sure you have two-factor auth enabled on your account.  This goes double if you're an Owner.
If you see something, say something.  A good example is people who are no longer involved with a project, but are still members of a team.
== Getting Help ==
If you run into an issue, contact an "owner" who has superuser privileges over the org and they'll be happy to sort it out.  One of the following folks would be a good starting point:
* Ryan Kelly
* Toby Elliott
== TODO ==
Everyone should be able to create a new repo in either org.  The "all of cloudservices" teams should be adjusted to enable this.
We should seriously consider a "mozilla-archive" org into which we can move obsolete and unmaintained projects.
Document what we need to know about accepting pull-requests, wrt copyright assignment and licensing and what-not.

Latest revision as of 22:16, 7 September 2014

Aside from some legacy projects in mercurial, all of the code for the Cloud Services team lives in GitHub. There are over a thousand Mozilla-related repositories on there in total, but no over-arching corporate policy on How Mozilla Should Use GitHub, so it can easily get a bit confusing - this document exists to help you make some sense of it all.

It's all guidelines, not actual rules. Do what works, but please review the below as well as the top-level Github info page.

Organizations

Cloud Services code is spread across two github organisations:

What code lives in which org is essentially a historical artifact. For new repositories, a simple rough guideline is:

  • Projects that are mostly infrastructure-related, or are heavily specific to Mozilla's internal needs, should go in "mozilla-services". Examples include Circus and Heka as well as various puppet configuration repos.
  • Projects that will be of more general interest to the Mozilla community, or that are more clearly aligned with Mozilla's mission and brand, should go in "mozilla". Examples include the Persona and Firefox Accounts application servers.

You will not have to look hard to find counter-examples to the above. Don't fret. Just do what you think is sensible.

Teams and Permissions

Access control to repositories in an organization is managed by teams. Please review the Teams Permission Model which is thankfully quite simple.

All Cloud Services Engineers should be members of the following teams:

If you're not a member (and getting a 404 when you visit the team page is a good indication that you're not) please contact an owner (see below) and they can fix it up.

We also have the following project-specific teams. If you're working on these projects, make sure you're in the appropriate team:

Security

Make sure you have two-factor auth enabled on your account. This goes double if you're an Owner.

If you see something, say something. A good example is people who are no longer involved with a project, but are still members of a team.

Getting Help

If you run into an issue, contact an "owner" who has superuser privileges over the org and they'll be happy to sort it out. One of the following folks would be a good starting point:

  • Ryan Kelly
  • Toby Elliott

TODO

Everyone should be able to create a new repo in either org. The "all of cloudservices" teams should be adjusted to enable this.

We should seriously consider a "mozilla-archive" org into which we can move obsolete and unmaintained projects.

Document what we need to know about accepting pull-requests, wrt copyright assignment and licensing and what-not.

Retrieved from "https://wiki.mozilla.org/index.php?title=CloudServices/Github&oldid=1012850"