...
- [ MES ] Acquire a new test Mac so we don't have to run on developer laptops. Even if we build GMAT on the test machine and unzip onto developer machines, we still have to split into two sets of tests due to VPN crapping out after 24 hours. We could explore if we can get this time increased to 48 hours, but I'm not optimistic on how easy it would be to waive IT's policies.
- [ DJC ] Release more frequently. That would have several benefits:
- It is easy to forget how to perform some steps. Two years between releases is too long.
- This release is quite complex, with many new features. More frequent releases would reduce that complexity.
- External teams waiting for fixes or new features would be less inclined to move to other tools.
Doing this would require: - A more streamlined release process:
- Internal: Perhaps make intermediate releases beta, but if so we muststick to the beta schedule.
- External: The release authority and other NASA approval chain entities would need to be prepped for this change.
- Merging of new features as they occur. (We should be doing this anyway.)
- [ SPH ] Create a note card commit/push check list.
- DSC Keep Mac regression test system in good shape. e.g., update to using a more recent Matlab version.
- [SN] Investigate the cost/benefit of including a Gitkraken pro license as a line item in the GMAT budget. Separately, consider voting on a uniform repo visualization tool for the whole team that works well and looks the same on all OS platforms.
- [ RM ] Write-protect the master branch, and STRONGLY encourage development on feature branches.
- This does NOT mean the master branch gatekeeper needs to review merges into master.
- This DOES mean that the branch owner will have to ask the gatekeeper to merge their branch into master. This will nearly eliminate accidental merges into master.
- This will not be a heavy task. The gatekeeper exists merely to ensure that branch owners don't accidentally merge into master.
- Look into whether the gatekeeper can be an automated script of some kind.
Stop Doing
- [ SPH ] The number of permutations of different packages is too large, zip, installer, public, internal, mac, linux, windows. I propose we consider only releasing a zip or installer on Windows to reduce the number of permutations of tests to run.
- [ MES ] An alternative to this is to run only smoke tests on either the zip or installer, with full tests on the other.
- [ MES ] Mac process currently runs full tests only on the internal version, on the theory that the public version is a subset of those capabilities. This approach may be reasonable on other platforms, with the addendum that all delivered versions should at least be smoke tested.
- [ DJC ] On Linux, perhaps move to a package based environment (e.g. Docker or Kubernetes)