Istanbul: Lessons Learned

Cannot complete arch reviews by M2.  Should we increase the time between M1 and M2? Some other solution?

Can we start arch reviews earlier? Limited by sign off for previous release.

Can we increase cadence of arch SC meetings for review period? Have additional meetings in other time zones?

Disconnect between arch reviews and release management processes.  Example:  DMAAP-1615

Verify that release name string is updated in documentation (i.e., “honolulu” release documentation showed release as “guilin”)

New task for M2:  PTLs complete color-coding of view-per-component GR requirements by M2 in order to highlight resource issues, or other problems, as early as possible.

Remove OOM tasks from M3 and move them to M4, since OOM activities trail project code review activities.

Testing task should happen after container delivery.  Move to RC? (Toine)

Jira cleanup for projects should move to Sign Off

Need to resolve ongoing issues with unmaintained projects:  simple bug fixes; publication of documentation, etc.

Problem at the front of the release with release management tasks for requirements owners.  Since requirements submission doesn’t end before M1, it’s possible for new requirements to be added AFTER the release management tasks have been added.  Difficult to track without a lot of manual effort.

RM to monitor requirements added to the release through M2 and update release management tasks accordingly.

Could requirement owners send notification to the requirements SC mailing list?

Cutoff at M2 prevents project teams from evaluating support.