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

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

Here are some comments:

• A Global requirement is a best practice. A best practice is a non functional or functional requirements There are currently 25 Global Requirements (12 non functional requirements and 13 functional requirements) identified for the Honolulu Release to be reviewed and prioritised by the ONAP TSC by 11/19. Since Honolulu is the prototype for the new release cadence, I wonder if we should ask the TSC to select only 1-2 items out of 25.
• How do we handle Global Requirements that were not selected by the TSC but have been developed for Honolulu Release?
• The current EPIC JIRA Release Management Template is considering all the previous milestones. Can we perform a mapping? Or shall we update the template and all the requirements already submitted.
• What are the expectations for the PTLs, Requirement Owners for each new milestone?
• Did we get any feedback from PTLs and from TSC members about their availability on Dec 17th, 2020 and assessment that Spec Freeze (former M1/M2/M3 milestones?) can be finalized at that time considering that we have not yet finalized Guilin release?

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.

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:

• Slides 2/3 - In the previous definition, a Global requirement is a best practice. A best practice is a non functional or functional requirements .  But Slides 2/3 are no more in alignment with the previous understanding. So we need to align the new definitions to become crystal clear. I would recommend to review the following wiki page - Honolulu Release Requirements  - what it is considered best practice, spec and feature and use case? I do not see any reference in these slides 2/3 about non functional requirements? Who/How the non functional requirements will be addressed - 'Taxing" on Feature/Spec requirement owners?
• Slide 2 - Best Practice = Design pattern recognized by the community. Should be followed by the new code but it is only enforced when it is recognized as global requirement? so it might be a big task later on if TSC does not approve it immediately and might generate a challenge for code submitted several releases and developers are not part of the ONAP Community?
• Slide 4: Spec Freeze = former M1 to M3 milestone? Feature Freeze= former Code Freeze milestone? What are the expectations set to the project teams, requirements owners, Subcommittees, TSC for each milestone from Kick-off to Sign-Off
• Slide 5 - Honolulu Release Kick-Off did not follow what it is defined in the slides. PTL did not provide feedback on Global requirements because these were only known at the Kick-Off so we should give time to the PTLs between Kick-Off and GR approval to provide feedback or did you expect that the community only provide GR after speaking to the PTLs?
• Slide 6 - I do not think that the PTLs can finalize their M1 release requirements by that time - i.e. 11/19. I would suggest that former M1-M3 milestones are completed as part of Spec Freeze
• Slides 7 to 19 (still under review)

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