...
| Description | Documented by | Comments / Follow-up | |
|---|---|---|---|
| 1 | Cannot complete arch reviews by M2. Should we increase the time between M1 and M2? Some other solution? | ||
| 2 | Disconnect between arch reviews and release management processes. Example: DMAAP-1615 | ||
| 3 | Verify that release name string is updated in documentation (i.e., “honolulu” release documentation showed release as “guilin”) | Thomas Kulik | |
| 4 | 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. | Implemented for Jakarta | |
| 5 | Remove OOM tasks from M3 and move them to M4, since OOM activities trail project code review activities. | ||
| 6 | Testing task should happen after container delivery. Move to RC? (Toine) | ||
| 7 | Jira cleanup for projects should move to Sign Off | ||
| 8 | Need to resolve ongoing issues with unmaintained projects: simple bug fixes; publication of documentation, etc. | ||
| 9 | 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. | ||
| 10 | Lessons Learned for the Documentation Project | Thomas Kulik | |
| 11 | Begin X-testing on release branch as soon as the branch is available | David McBride | |
| 12 | Get legal assessment on release no later than M3 | Kenny Paul |