...

Other aspects (should they be standardized among all SLAC?)

Repository

...

naming

Should we standardize for repository naming or keep each team to define them freely? Use cases:

...

• No module prefix
• No extension prefix
• Prefix IOC applications with ioc-?

Standard

...

rulesets

Should the entire SLAC follow the same workflow, with standard names for branches, and standard rules for using each branch? What if different departments have conflicting requirements? 

...

• Mirror TID-ID workflows
  • Git workflow for the Embedded Group
• Match branches:
  • main
  • pre-release
  • Release tags (in the format [0-9]+.[0-9]+.[0-9]+ 
    • NOTE: GitHub uses fnmatch, not regexp for this matching.
• Allow bypass:
  • Maintainers and repository owners
• Restrict creations
• Restrict updates
• Restrict deletions
• Require a pull request before merging
  • Require at least 1 approval before merge
• Require status checks to pass
  • Only if CI is enabled

Future Work

Not for the current organization proposal.

Standards for commit names

Should we standardize commit names across all SLAC? ECS has been using a model: https://pcdshub.github.io/development.html#commit-guidelines.

Standards unrelated to GitHub

Do we want to standardize code best practices and documentation across SLAC?

Establish Standards for Locally Developed C/C++ Projects

ipmiComm and ek9000 module should could be used as the reference implementation for these things.
These two modules should implement most or all of the recommended CI checks and whatnot, and adhere to the standards we define.

• GitHub actions for CI. Verify things compile that everything compiles to avoid broken code being merged.
• Set -Werror, minimize ignored warnings
  • Define standard set of enabled/disabled warnings for C/C++ projects
• Some level of automated testing, (OPTIONAL)
  • Testing should be run with a runtime analyzer too
    • asan
    • valgrind
  • Testing may not always be possible due to the nature of EPICS
• Static code analysis with clang-tidy
  • Define standard set of clang-tidy checks
• Code formatting with clang-format (OPTIONAL)
  • Define standard clang-format configuration (ideally one that closely matches our current, most common style)

...

• Generate documentation using:
  • Sphinx (Restructured Text) (any, but mostly Python)
  • Doxygen or clang-doc (C, C++)
  • LaTeX (any)
• Publish documentation to GitHub pages
  • See asyn and friends for a CI setup here: https://github.com/epics-modules/asyn/blob/master/.github/workflows/publish-docs.yml

Establish Standards for Commit Names

• Git workflow for embedded group does not define commit naming guidelines
• Perhaps we want to define some, like PCDS does?
• See https://pcdshub.github.io/development.html#commit-guidelines

Document Contribution Workflow on GitHub Pages

• Again, like PCDS Like ECS does: https://pcdshub.github.io/development.html
• They also briefly describe their various repositories so newbies can figure out where to find what.
• Links in the side bar too!!.