Date | Event or Update | Milestones Affected |
---|
Apr 29 | TSC approved Honolulu sign-off | Sign-Off |
Apr 15 | TSC approved schedule (r5) | RC1, RC2, Sign Off |
Apr 8 | Proposal for RC1, RC2, Sign Off (r5) (Note: r4 proposed but not approved) | RC1, RC2, Sign Off |
Apr 2 | Proposal for RC1, RC2, Sign Off (r4) | RC1, RC2, Sign Off |
Apr 1 | Consensus with OOM and INT that RC0 requirements met (TSC e-mail vote in progress). Action to propose schedule for RC1, RC2, Sign Off | RC0 |
Mar 29 | RC0/RC1 requirements not met. Re-evaluate on April 1. | RC0, RC1 |
Mar 25 | RC0/RC1 requirements not met. Re-evaluate on Mar 29. | RC0, RC1 |
Mar 18 | TSC approved plan to merge RC0 with RC1 on March 25 | RC0 |
Mar 11 | TSC approved schedule proposal (see Mar 10 below) | RC0, RC1, RC2, Sign Off |
Mar 10 | Blocking issue reported for RC0. Propose 1 w slip to RC0 → Sign Off (r2). Sign off moves to April 8. | RC0, RC1, RC2, Sign Off |
Mar 1 | TSC approves M3 with exceptions. Exceptions to be closed by RC0. | M3 |
Feb 25 | TSC determined that there is insufficient information to make decision, so M3 pushed out 4 days to March 1 | M3 |
Feb 1 | Uploaded ONAP Honolulu r1 to show changes to M1 and M2 dates | M1, M2 |
Jan 25 | M2 approved with exceptions | M2 |
Jan 21 | Requirements not met. M2 slipped to Jan 25 | M2 |
Jan 14 | M1 approved with exceptions | M1 |
Jan 11 | Requirements not met. M1 slipped to Jan 14 | M1 |
Dec 10 | TSC approved schedule | ALL |
Dec 10 | M1 moved out 4 days to Jan 11 | M1 |
Nov 20 | Second draft posted |
|
Nov 11 | First draft posted |
|
7 Comments
Michela Bevilacqua
HI,
should we now consider the following plan as the final Rel H planning ?
It could be very good update this page with the relevant information/milestones for Rel H
David McBride
Hi Michela Bevilacqua ,
The first draft of the schedule has been posted. We will discuss it during the TSC call on Nov 12. The milestones and timing are based on the proposal from Krzysztof Opasiakand Chaker Al-Hakim. This draft schedule was produced with their assistance.
David
Catherine Lefevre
Here are some comments:
Dan Timoney
In the proposed new release cadence proposal, containers must be "delivered to OOM" by Feature Freeze - which means that all code must not only be submitted, reviewed, and merged, but all repositories be released. For projects with multiple repositories, this typically takes several days. So, in order t meet a 1/28 Feature Freeze date, final code would need to be submitted no later than 1/21 to allow time for completing the code review / release process. in fact, we probably need to move that back even further to allow time to assess whether all approved GRs have been delivered and to take corrective action if not. That does not seem like a realistic time frame, unless of course the content is quite small.
Catherine Lefevre
I have reviewed the following deck "https://wiki.onap.org/download/attachments/92998580/release%20cadence%20for%20ptls.pptx?version=1&modificationDate=1605535660000&api=v2", please find my comments:
Catherine Lefevre
Slide 8 - Previously we agreed that the release branch will be created at RC0 (after pair-wise testing completion) because a lot of issues are found between code freeze and pair-wise testing activities. Why has triggered the fact that now we are suggesting to branch the release so early? Containers delivered to OOM might not be great and will probably break the build since pair-wise testing not performed.
Slide 9 - what type of testing? are we still in alignment for Pair-Wise testing?
Slide 14 - Branching at Feature Freeze too early and will require cherry-picking work between master and release branch. It is also not aligned with previous plan submitted and approved by the TSC.
Slide 15 - There is no way that the PTLs will provide the requested information by 11/19 (M1) date so suggestion to move this request by Spec Freeze milestone
If we do not assign issues to a release then how do we know what's the content of a release?
Today FOSS has not automated so how can we move forward?
Slide 16-Release Planning Template removed - but can we have a consistent way for the PTLS to report their commitments? honolulu requirements colors or something else?
Slide 17 - I do not understand what it is about "Define rules of patch inclusion for this release "
Other questions:
*no notion of Test coverage % - this was a quality factor per project - where is it tracked now?
*Can you also add what we expect from Requirement owners, test leads for each milestone?
*We need to track when the Key updates for the Marketing team is available - at RC0/RC1
*No reference to RC2 while Honolulu Schedule is highlighting it. What do we expect at RC1 and RC2?
*Revert all the code for a project if GR not met – it has a cascade effect on other projects that are dependent on each other
Jim Hahn
Appears that the dates should be updated.