Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Table of contents

Table of Contents

 

Info

Target Date: May 14, 2014

Tasks

Info

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.

Early Tasks

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

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

TaskWhoStatus

Internal

Status

Notes

Review Previous Build Release R2013b Process Notes

All(error)(error) 
Get updated legal statement/licenseSPH(tick)(tick)Needed by Code Freeze.
Update sample scripts
SPH(tick)(tick)

Needed by App Freeze.

  • Write examples that demonstrate new functionality
  • Clean up all errors and warnings
  • Remove deprecated fields
Write draft Release Notes

JJKP

SPH

(tick)(tick)

Needed by App Freeze.

See Writing Release Notes

Update standard descriptive textSPH(error)(error)

Needed by App Freeze.

Will be used in User Guide, websites, release announcement.

Update info on public-facing websitesJJKP(error)N/A

Needed by Release Day.

See the list of sites. Update this list as well, if necessary.

Updated major sites before announcement. Minor ones can be updated a bit later.

Update release announcement contactsSPHN/AN/A

Needed by Release Day. Located here.

Put in order for additional iconsSPHN/AN/A

(if necessary)

Needed by Visual Freeze.

For QA Complete (April 21)

QA complete means that all known bugs are being tracked, all bug fixes are verified and documented, and the release process can begin.

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

 

TaskWhoStatusNotes
Verify that all known bugs are checked into JIRA(All)RQ: (tick)RQ: I'm done with this
Complete all JIRA verifications(All)RQ: (tick)RQ: I'm done with this
Complete QA wrap-up tasksDSC, SPH, JJKP, RQ

RQ: (tick)

RQ: I'm done with this

Address all JIRA tickets awaiting feedback(All)RQ: (tick)RQ: I'm done with this

For Visual Freeze (April 30)

...

Release Process Work Before next Cycle for R2015a

  • NTR needs to go in months (3-6) earlier
  • Define major roles and assign them to individualsbefore next release
    •  Proposed roles are shown below.
    • Ensure those in major roles are reachable and preferably in the office during critical stages like creating and testing RCs.
  • Consider merging to production and test this before next release process
  • Automate installer packaging
  • Consider sanity check from mission users' scripts
  • Feature Freeze/QA Complete/Beta Test must happen earlier (month before code/App Freeze)
    • We need to baseline the test results well before release process starts.  Probably at Feature Freeze\QA Freeze
    • Consider allowing GATS to produce multiple reports from one test run
    • Consider feature freeze month before
    • QA Complete needs to happen much earlier (month?) probably with Feature Freeze

Proposed Roles For Next Release for R2015a

  • Release Manager (RM): "owns" release, initiates process, creates tracking page, sends daily status updates, tracks issues to completion, makes sure everyone gets their stuff done, brings decisions to CCB/team, maintains tracking page, collects lessons learned, documents process improvements for next release
  • Build Manager (BM): controls build system, creates RCs, sends RC availability announcements
  • Test Managers (TM): control GUI/script testing for each RC

 

Info

Target Date: May 14, 2014

Tasks

Info

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.

Early Tasks

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

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

TaskWhoStatus

Internal

Status

Notes

Review Previous Build Release R2013b Process Notes

All(tick)(tick) 
Get updated legal statement/licenseSPH(tick)(tick)Needed by Code Freeze.
Update sample scripts
SPH(tick)(tick)

Needed by App Freeze.

  • Write examples that demonstrate new functionality
  • Clean up all errors and warnings
  • Remove deprecated fields
Write draft Release Notes

JJKP

SPH

(tick)(tick)

Needed by App Freeze.

See Writing Release Notes

Update standard descriptive textSPH(tick)(tick)

Needed by App Freeze.

Will be used in User Guide, websites, release announcement.

Update version number on User Guide cover pageJJKP(tick)(tick)

Needed by App Freeze.

Contact Katy Gammage or Mary Hrybyk-Keith.

Next time: integrate sejda-console to do this automatically.

Update info on public-facing websitesJJKP(tick)N/A

Needed by Release Day.

See the list of sites. Update this list as well, if necessary.

Updated major sites before announcement. Minor ones can be updated a bit later.

Update release announcement contactsSPHN/AN/A

Needed by Release Day. Located here.

Put in order for additional iconsSPHN/AN/A

(if necessary)

Needed by Visual Freeze.

For QA Complete (April 21)

QA complete means that all known bugs are being tracked, all bug fixes are verified and documented, and the release process can begin.

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

 

TaskWhoStatusNotes
Verify that all known bugs are checked into JIRA(All)RQ: (tick)RQ: I'm done with this
Complete all JIRA verifications(All)RQ: (tick)RQ: I'm done with this
Complete QA wrap-up tasksDSC, SPH, JJKP, RQ

RQ: (tick)

RQ: I'm done with this

Address all JIRA tickets awaiting feedback(All)RQ: (tick)RQ: I'm done with this

For Visual Freeze (April 30)

Visual Freeze finalizes all graphical changes to the software, so that screenshots, documentation, and TestComplete can be updated.

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

TaskWhoStatus

Internal

Status

Notes
Update About panel

LOJ

(tick)(tick)
  1. Update release number (i.e. R2014a).  
  2. Add any new libraries used. 
  3. Update an links.
Update splash screenTGG(tick)(tick)
  1. Add new contributors
  2. Remove contributors who did not contribute to this release
  3. Design updates
  4. Update SplashScreen.psd in GmatDevelopment\moredata\graphics\splash
  5. Use GIMP to save a flattened TIF file and overwrite splash screen in GmatDevelopment\application\data\graphics\splash.
Update iconsTGG(tick)(tick)

If there are any updates, additions, deletions.

Including GMATIcon for Welcome Page

Update gmat_startup_file.txtJJKP(tick)(tick)
  • Update formatting, comments
  • Add any additional plugins
  • Switch to release configuration (comment out internal plugins)

No new plugins added. Commented out internal plugins.

Switch to release configuration in script test system

JJKP(tick)(tick)
  • Create new rundef.R2014aInternal.template.m and rundef.R2014aPublic.template.m.
  • Switch autorun.m to use appropriate one.

4/30: switched to R2014aInternal

7/17: tested public release using R2014aPublic

Complete visual updates(All)(tick)(tick)

4/30: JJKP: still waiting on final updates to contributors list from KARI

5/2: TGG: final update committed

For Code Freeze (April 30) 

Code Freeze is a freeze on the software itself before final testing.

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

TGGJJKP
TaskWhoStatus

Internal

Status

Notes
Update About panel

LOJ

(tick)(tick)
  1. Update release number (i.e. R2014a).  
  2. Add any new libraries used. 
  3. Update an links.
Update splash screenStatus

Internal

Status

Notes
Update EOP filesWCS(tick)(tick)
  1. Add new contributors
  2. Remove contributors who did not contribute to this release
  3. Design updates
  4. Update SplashScreen.psd in GmatDevelopment\moredata\graphics\splash
  5. Use GIMP to save a flattened TIF file and overwrite splash screen in GmatDevelopment\application\data\graphics\splash.
Update iconsTGG(tick)(tick)

If there are any updates, additions, deletions.

Including GMATIcon for Welcome Page

Update gmat_startup_file.txtUpdate eopc04_08.62-now and run smoke tests.
Update files w/ updated legal statementLOJ(tick)(tick)
  • Readme file
  • Source code files
Update license textLOJ(tick)(tick)Update formatting, comments
  • Add any additional plugins
  • Switch to release configuration (comment out internal plugins)
  • No new plugins added. Commented out internal plugins.

    Switch to release configuration in script test system

    JJKP(error)(tick)
    • Create new rundef.R2014aInternal.template.m and rundef.R2014aPublic.template.m.
    • Switch autorun.m to use appropriate one.

    4/30: switched to R2014aInternal

    Complete visual updates(All)(error)(error)

    4/30: JJKP: still waiting on final updates to contributors list from KARI

    5/2: TGG: final update committed

    For Code Freeze (April 30) 

    Code Freeze is a freeze on the software itself before final testing.

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

    TaskWhoStatus

    Internal

    Status

    Notes
    Update EOP filesWCS(tick)(tick)Update eopc04_08.62-now and run smoke tests.
    Update files w/ updated legal statementLOJ(tick)(tick)
    • Readme file
    • Source code files
    Update license textLOJ(tick)(tick)Update application/License.txt file.
    Final bug fixes(All)(tick)(tick) 
    Mark all open bugs as Affects: current releaseSPH(tick)(tick) 

    ...

    application/License.txt file.
    Final bug fixes(All)(tick)(tick) 
    Mark all open bugs as Affects: current releaseSPH(tick)(tick) 
    Warning

    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

    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:

    1. 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)
    2. 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 (May 5) 

    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 ((tick)) and "(x)" for the cross ((error))

    ...

    RC1: (tick)

    ...

    )

    TaskWhoStatusNotes
    Update README.txtJJKP

    RC1: (tick)

    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: (tick)

    RC2: (tick)

    RC2-2: (tick)

    RC3: (tick)

    RC4: (tick)

    RC5: (tick)

    Version string: R2014a-rc#

    Next time: build manager should do this

    Bundle Windows zip

    JJKP (backup: TGG)

    Bundle Windows zip

    JJKP (backup: TGG)

    RC1: (tick)

    Version string: R2014a-rc#

    RC1RC2: (tick)

    RC2-2: (tick)

    RC3: (tick)

    RC4: (tick)

    RC5: (tick)

    Version string: R2014a-rc#

    Next time: build manager should do this

    Run TestComplete smoke testsTRRC1: (error) (tick)These are tests on the packaged versions of GMAT: the installer and the zip bundle.
    Run TestComplete system test missionsTRRC1: (error) (tick)These are tests on the packaged versions of GMAT: the installer and the zip bundle.
    Run script test systemJJKP (backup: TGG)

    RC1: (tick)

    RC2: (tick)

    RC2-2: (tick)

    RC3: (tick)

    RC4: (tick)

    RC5: (tick)

    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 scriptsSPHRC1: (error)

    RC2: (tick)

    RC4: (tick)

    At a minimum these need to be run individually by hand.  I ran them by adding the folder, and they run so fast I missed some pretty big problems.  Ideally, these should all be in script regression tests.  Many but not all already are regression tested.  Or, we should add them to GUI regression system.
    Run TestComplete full regression testsTR(error)

    RC4: (tick)

    RC5:

    (tick)

    (For final RC only)
    Info
    titleNotes
    • While this cycle is ongoing is a good time to do wiki updates and cleanup.

    ...

    TaskWhoStatusNotes
    Bundle source code and upload to SourceForge
    DJC*(error)(tick)(error)
    1. Export the trunk code from svn that is used for the release build when that build is started
    2. Wait for a go/nogo call from testing on the build
    3. Archive the following folder trees into a zip file: src, plugins, build
    4. Move the zip file to SF
    5. Mark as "staged"
    6. Download the upload and check it
    Bundle data and upload to SourceForgeDJC
    1. the following folder trees into a zip file: src, plugins, build
    Bundle data
    DJC*(tick)
    1. Use the same export as used for the source bundle
    2. Wait for a go/nogo call from testing on the build
    3. Archive the following folder tree into a zip file: application/datazip file: application/data
    Upload source bundle to SourceForgeJJKP(tick)
    1. Move the zip file to SF
    2. Mark as "staged"
    3. Download the upload and check it
    Upload data bundle to SourceForgeJJKP(tick)
    1. Move the zip file to SF
    2. Mark as "staged"
    3. Download the upload and check it
    Upload Windows installer to SourceForgeJJKP(error)(tick)Download, install, and run after uploading.
    Upload Windows zip to SourceForgeJJKP(error)(tick)Download and run after uploading.
    Post README.rst.txt on SourceForgeJJKP(error) (tick)Update for new release
    Upload docs to documentation siteJJKP(tick)
    1. Upload using SSH to http://gmat.sourceforge.net/docs/
    2. Update HTML with new section
    3. Move "latest" pointer to new folder
    Post internal & public release files to MESA networkJJKP(error) (tick)2014-05-22: posted internal files only; public files are in build\VS2010_build\R2014a

    Branch and tag repositories

    JJKPDJC(error)(tick)At least tag the test system; consider branching also if the burden on the repo is low.
    Make SourceForge repository backupJJKP(error)(tick)

    Follow SourceForge's instructions.

    Perform the backup on the Linode server and download the resultant .zip file, since the local network blocks rsync.local network blocks rsync.

    * DJC can only do steps 1-3 here because of contractual constraints

    Release Day (May 14)

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

    TaskWhoStatusNotes

    Make files visible on SourceForge

    SPHJJKP(error) (tick)07/21: Made visible at time of posting, as "soft" release.
    Send out release announcementSPH(error)(tick)
    • Mention GSFC in the announcement
    • Don't include large attachments.
    Post release announcement on SourceForgeDJCSPH*(error)(tick) 
    Post release announcement on GMAT BlogJJKP(error) Mark as released in JIRASPH(error) (tick) 
    Mark as released in JIRASPH(tick) 
    Migrate code to SourceForge repositoryJJKP(tick)Do we migrate to git at the same time?

    This needs to be assigned to a different person; DJC cannot post to SF

    Post-Release

    Use "(/)" for the checkmark ((tick)).

    TaskWhoStatusNotes
    Party!(All)(error)

     

    Print materials
    JJKP(error)
  • Printed documentation (reference booklet, full User Guide)
  • Release CDs(All)
    (tick)

    Plan for week of June 19

    Conduct postmortem reviewSPH(error)(tick)This includes gathering feedback, holding the postmortem meeting, and documenting the results.
    Submit GSFC Metrics SummarySPHWCS Measurement summary tool must  be submitted for each major build(tick)The link to submit the metrics is invalid.No action is required for this item. It was decided on 09/25/14's GMAT meeting to check tasks that do not require any action or are inactive.
    Submit NTR for next releaseSPH(error) 
    Spring cleaning?(error)

    General cleanup of infrastructure:

      • Wiki
      • \\mesa-file\595\GMAT
      • get rid of old SVN branches
      • anything else?
    (tick) Per Hughes: The NTR cannot be written until all features are finalized and it is too early to do that.

    Notes for postmortem

    Please add your notes to the R2014a Lessons Learned document.

    ...

    1. Create the build
      1. Log into gs580w-gmat-t4 as "gs580w-gmat-t4\builduser". The credentials are on the network drive, in the Infrastructure folder.
      2. Start Task Scheduler.
      3. [RC1 only] Disable the "GMAT Daily Build" task, so it doesn't run automatically during the RC cycle (this can make things overly confusing).
      4. Manually run the "GMAT Daily Build" task.
      Create the bundles
      1. On your local system, navigate to SourceForge\trunk\build\install\windows-nsis. There" task.
    2. Create the bundles
      1. 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.
      2. Open a MinGW Shell in this directory.
      3. Run "make VERSION="R2014a-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="R2014a-rc#". 
      4. Copy the four package files to the network: \\mesa-file\595\GMAT\Builds\windows\VS2010_build\R2014a
      5. To clean everything up afterwards, run "make clean".
    3. Run the script test system on the internal installer package. See Running the script test system, below.

    ...