...
- [ 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.
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)