Development and Release Protocols

The goal of this document is to develop a formal software management plan for the GridPACK software stack

Current Practice: Software management currently consists of the following elements

1. Software is stored in a Github repository which enables developers to create branches, merge their changes with those of other developers, and keeps track of code history as well as providing a mechanism for limiting the developer pool to trusted developers. It also provides a mechanism for reverting back to older versions of the code in case of some catastrophic failure.
2. Nightly builds are performed using Jenkins and checked for correctness. Failures are flagged and a message sent to development leaders. The current version of the code in the master branch in the Github repository is downloaded each night and used as the basis for the Jenkins build. The Jenkins build only tests the code on a single platform.
3. Prior to a release, a release branch is created and team members hand test the configuration and build of the release candidate on a variety of operating systems. These consist of a combination of native installations and virtual machines. An action item is to document this list more fully and fill in any gaps.

The platforms (informally) that are currently being used to test the GridPACK build and execution are

1. RHEL6 (constance)
2. RHEL7 (prusik)
3. Ubuntu 18.04 (Yousu?)
4. Ubuntu 16.04 (VM)
5. Centos6 (VM??)
6. Centos7 (VM)
7. MacOS (High Sierra)
8. Debian(VM??)

The number of developers contributing to GridPACK is still relatively small and there is no formal process for approving changes. External developers can push changes to GridPACK and these are reviewed by the GridPACK developers before being merged with the main development branch. Possible actions:

1. Formalize the list of platforms on OS’s that are tested before a release so that we have a clear picture of exactly what is being evaluated. We may want to look at extending this list to use some cloud machine images. (See comments above).
2. Extend the testing of nightly builds to cover more machines. We may want to look at Travis. Currently we are using a Jenkins-based testing harness.
3. Formalize the mechanism for modifying the main developer branch. Perhaps all development is on user branches and then merged to main branch.