Page History
...
| Term | Description |
|---|---|
| Organization | A location on GitHub where many repositories and teams can be stored. Translates into a URL when browsing or cloning a repository. |
| Working Copy | A clone of a Git repository that you can edit and compile. |
| Repository | A location where Git history and code are stored. These are added as "remotes" on a local working copy. |
| GHE | GitHub Enterprise |
| HLA | High-Level Applications |
| Fork | A copy of a repository from one organization to another. For example, github.com/slac-epics/asyn would be a fork of github.com/epics-modules/asyn. GitHub keeps track of forks so the upstream code has the link clearly visible. |
| Upstream | Repository that is the original basis of a fork. |
GitHub Organization
Analysis of proposals
We've analyzed different ideas:
- Single organization for all the code created at SLAC:
- We tried this and soon we started to face problems with naming conflicts.
- To solve this we would need to modify the name of the repositories appending something that would group them. For example, all EPICS support modules would have "epics-" prepended. This way asyn would become epics-asyn.
- The naming change was not ideal because we would like to fork an external module and have the name coincide with the upstream code.
Given that slaclab has hundreds of repositories, a naming conflict was very probable. We decided that we needed some level of repository grouping without creating too many repositories.
One idea of grouping would be to have one GitHub organization per SLAC directorate. This idea was abandoned because:
- It creates a virtual wall, psychologically discouraging collaboration between directorates.
- It breaks related repos into different organizations. For example, EPICS modules would be spread in different GitHub organizations.
- It difficults transfer of ownership if this ever happens.
...
slaclab
slaclab is the organization that is the default starting point for all repositories maintained by SLAC. When thinking about the right place to create a new repository, the first answer is slaclab.
URL: https://github.com/slaclab
User access to this organization will probably be handled by SSO with the GitHub Enterprise account, meaning that if you already have an SLAC account, your access should be automatically allowed.
Questions to be answered:
- What happens when a person leaves SLAC?
- What happens if the person leaving still contributes with code?
- How do we address contributions from people outside SLAC?
slac-sandbox
slac-sandbox is an organization for hosting repositories that will be short-lived, like prototypes, code practice, and proof of concept. It is ok if a repository in slac-sandbox is transferred to slaclab if it makes sense.
Creating new organizations
New organizations should seldom be created. A few arguments that could justify a new organization:
- If name collisionsemerge(gateway, bsa, base, etc.)
- If managing 100+ repos within slaclab gets burdensome.
- Collaborating with external developers on multi-repo projects. For example: EPICS archiver appliance.
- Self-managing private repositories without visibility from org admins (projects involving NDA).
Current proposal
- slac-epics
- Name is still undecided. Other options: slac-epics-support, slac-epics-infra
- Components that do not belong in slac-epics-apps, but depend on the EPICS build system and/or EPICS base
- Examples:
- EPICS base
- EPICS modules
- EDM
- ALH
- eco_tools
- Striptool
- Gateway
- eget services
- slac-epics-apps
- EPICS applications of all kinds, usually they will be specific to a part of the lab rather than shared
- Examples:
- EPICS IOCs from all directorates, like EED and LCLS.
- EPICS HLAs
- PyDM and EDM screens
- Matlab code that uses EPICS
- NOTE (5/1/24): Likely want to merge this with slac-epics
- slaclab
- Everything else.
...
Overview
Content Tools