Delta V computation from finite burn is not on task and harder than SPH's origional idea.

SDO is evaulating if approximations are good enough. Since the maneuvers times are short, dt*thrust is an excellent approximation for delta-V. Preliminary tests indicate about 1% error using approximation.

The main question from SDO was whether the approximations are good enough for the delta H maneuvers. They see 5 sig figs which is good enough. The approximation is not good enough for large maneuvers they plan far in the future. Current plan is to change SOW deliverables for R2016b to include integration of delta V to ensure long term needs are met. Deliver R2016a with the approximation.

DSC

Closed

Alpha/Beta Features are exposed but not easy to turn off. FileThrust, GUIs for Nav components

This is being tracked on GMT-4862. This does not seem to be a tall pole. Propose closing as not a risk, just work that needs to be done. Still need a plan for disabling untested data types.

Scrub things that should be disabled. For example, old syntax like DataFile, MeasurementModel. This is being tracked in JIRA.

DSC

Closed

May need to use RedHat 6.?.

Might need to use Windows, status of Linux for ODT is unknown.

FDF is running Linux 7, with workaround for ssh.

TGG

Closed

Installer for cross platform supporting SVN data update utility

Current plan is that Data Update Utility will be included only if time allows, and that means time to fix issues and get installer working. Note, we probably do not need installer fro RC1, so that work could be pushed back until September if need be.

Data file update utility will not be in R2016a, it will be in R2016b.

Tasks

All dates are referenced to 12:00 noon EDT.

For example, a deadline of March 15 should be interpreted as March 15, 12:00 noon EDT.

Git Repo Branching Policy

This is our branching strategy during RC testing by the FDF for ODT.

We will create a new R2017aTemp branch from master, and developers working on code changes for R2017a would work in R2017aTemp.

Those working on docs, app freeze items, and the few remaining code updates for R2016a keep working in master.

Code changes for master could continue to require code reading and CCB approval.

Once we've promoted the RCs to release builds, we'll first branch R2016a from master, then merge R2017aTemp back into master and return to normal branching/commit policy.

Early Tasks

These are long-lead early tasks that can be completed before the detailed release cycle.

For this release: Should we branch the repo here, instead of after release? We need to allow people to continue working on unrelated items while release work is ongoing.{warning

(DJC here) A better approach going forward would be to merge master into production, and switch the test system to the production branch. This probably ought to be done right before building RC1. The dev team would have 2 options then:

Checkout branches based on what they are working on (i.e. checkout production for bug fixes for the release, and their current clone of master – every one is cloning for new work, right? – for ongoing work)

Alternatively, make bug fixes in master and cherry-pick merge changes into production as bugs are fixed

The former is the better approach, IMO, because it ensures that the bug fix is made on the current code base for the release.

For App Freeze (Sept. 15)

App Freeze is a freeze on all application bundle files beyond data and code. This includes documentation, sample scripts, stuff in the extras folder, etc.

Use "(/)" for the checkmark () and "(x)" for the cross ()

Task

Who

Status

Notes

Update README.txt

SPH

SPH:

WCS:

DJC:

Update with major release highlights.

Update extras folder

SPH

Notepad++ syntax coloring file

Update PDF files in docs folder

SPH/DJC

DJC:

SPH:

Waiting for final user guide.

Update watermark: "Draft for Release R2016a"

Put into application/docs folder, and individual doc source folders

Gather list of compatibility changes since last release

SPH

Deprecated fields

Removed & disabled fields

Anything a user would need to know to make R2016b scripts compatible with this release.

Update Release Notes

SPH

Update screenshots in User Guide

(Feature leads)

SPH:

RQ:

DSQ:

Test User Guide instructions & code

(Feature leads)

RQ:

DSQ:

SPH:

Tutorials

script snippets

reference page examples

SPH: only tested features that changed for which I was FDE

Update Windows installer package

TGG

Update links in GMAT.ini

TGG

Help links

Welcome page links

Update link tests in TestComplete

TR

Help buttons

Welcome Page links

Help menu links

Testing of Release Candidate 1 (Aug. 15 - Sep. 15 )

This will start with the 2014-05-05 daily build. Repeat this phase until tests check out. Steve will make the call.

Use "(/)" for the checkmark () and "(x)" for the cross ()

Task

Who

Status

Notes

Update README.txt

JJKP

RC1:

RC2-RC5: N/A

Next time: this should probably be "Update Release Notes" to add outstanding bugs, etc.

Build Windows installer

JJKP (backup: TGG)

RC1:

RC2:

RC2-2:

RC3:

RC4:

RC5:

Version string: R2015a-rc#

Next time: build manager should do this

Bundle Windows zip

JJKP (backup: TGG)

RC1:

RC2:

RC2-2:

RC3:

RC4:

RC5:

Version string: R2015a-rc#

Next time: build manager should do this

Run TestComplete smoke tests

TR

RC3:

These are tests on the packaged versions of GMAT: the installer and the zip bundle.

Run TestComplete system test missions

TR

RC3:

These are tests on the packaged versions of GMAT: the installer and the zip bundle.

Run script test system

JJKP (backup: TGG)

RC1:

RC2:

RC2-2:

RC3:

RC4:

RC5:

Run the internal installer tests on T4 and the public installer tests on Joel's machine. Run .zip bundle tests afterwards on same build to compare.

Test all sample scripts

SPH

RC3:

RC4:

At a minimum these need to be run individually by hand or run in GUI regression system. Additionally, they must be run on a system that has no other installations of GMAT. Past experience has shown that missing files, and configuraiton issues are not caught by running on machines used for development.

Run TestComplete full regression tests

TR

RC3:

RC4:

(For final RC only)

Notes

While this cycle is ongoing is a good time to do wiki updates and cleanup.

Stage Release (Sep. 25)

This is a soft release, putting all the files in place and updating information. Then on release day, we only need to send the announcements.

Use "(/)" for the checkmark () and "(x)" for the cross ()

Task

Who

Status

Notes

Bundle source code

DJC*

Export the trunk code from svn that is used for the release build when that build is started

Wait for a go/nogo call from testing on the build

Archive the following folder trees into a zip file: src, plugins, build

Notes for postmortem

Compatibility changes

Creating an RC

Log into gs580w-gmat-t4 as "gsfc580gmatbuild". The credentials are on the network drive, in the Infrastructure folder.

Start Task Scheduler.

[RC1 only] Disable the "GMAT Daily Build" task, so it doesn't run automatically during the RC cycle (this can make things overly confusing).

Manually run the "GMAT Daily Build" task.

Create the bundles

On your local system, navigate to GmatDevelopment\build\install\windows-nsis. Note that you do not need to pull files down from the Git repository; this process will pull files from the remote build and create the packages in your local directory. There's a README.txt file there that explains things.

Open a MinGW, MSYS2, or Cygwin shell in this directory.

Run 'make assemble VERSION="R2015a-rc#"', where "#" is the number of the RC you're creating. This will create two directories in the current directory: gmat-internal and gmat-public.

Run the following commands to add the User Guide cover. This requires sejda-console.

Run 'make VERSION="R2015a-rc#"', where "#" is the number of the RC you're creating. This will create four packages in the current directory: A .zip and a .exe file for both the internal and public versions. Note: To create only an internal version, run 'make internal VERSION="R2015a-rc#"'.

Copy the four package files to the network: \\mesa-file\595\GMAT\Builds\windows\VS2013_build_32\R2015a

Update the test system repo (located at C:\Users\gsfc580gmattest\Documents\GmatTest)

In MATLAB (64-bit):

Run:>> cd C:\Users\gsfc580gmattest\Documents\GmatTest\bin

Run (replace # with RC number and <config> with "internal" or "public"):>> diary('..\log\R2015a-rc#-<config>.log')

Run (this command copies application files such as SPICE kernels needed for regression tests into the new installation of GMAT):>> preparegmat('C:\Path\To\GMAT')

In C:\Users\testuser\Documents\GmatTest\bin, copy the appropriate template (autorundef.R2015aInternal.template.m or autorundef.R2015aPublic.template.m) to a new name (such as autorundef.R2015aRc1Internal.m) and fill in the values:

RunDef.Build: "R2015a-rc#-<config>"

RunDef.GmatExe: path to installed GMAT.exe

RunDef.RegressionBuild: last build date if testing RC1 (look in GmatTest\output for latest folder, such as 2013-07-31), otherwise, "R2015a-rc#-<config>"