Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

David McBride created a set of milestones for the different projects.

It is obviously impossible to be generic due, RM asks "specific" project to review the milestones according to their scope

See Generic Milestones descriptions: Frankfurt Deliverables by Milestone

+ Focus on Frankfurt Milestone Status


Here are the current requirements for M4 (generic):

  • New 3rd party dependencies, new FOSS (final confirmation)
  • License scan issues addressed
  • Address all security issues
  • All high/highest priority jira tickets addressed
  • Update Frankfurt Release Platform Maturity, CII badging update - update M4 Result
  • Test coverage goals complete
  • No Gerrit requests older than 36 hrs.
  • Integration weather board update
  • Update Frankfurt Risks

I would appreciate if each of you could do the following:

  • Identify which tasks from the list above make sense for your project.
  • Identify additional tasks that would make sense for your project.


M4 Integration criteria Proposal - note we should also review the previous milestones...

General

  • License scan (integration/*, testsuite/*, demo/*)  issues addressed
  • No Gerrit requests older than 1 week
  • Update Frankfurt Risks
  • All high/highest priority jira tickets addressed (blocking integration board ready)

Labs

  • Resources secured for release validation (if needed some resources may be pre-empted) - at least 2 labs available for testing

Use cases

  • Integration use case weather board update - use cases frozen (only status update allowed)
  • Documentation shall be initiated (at M2/M3)

CI/CD

  • Daily Master => Daily candidate (here Daily Frankfurt) running on at least 2 labs
  • Stability test ready for Daily Frankfurt?
  • Testing dockers and testing declared in the DB frozen

Tests

  • New tests done on Master only (no backport to Frankfurt)
  • Ideally the code of the test should also respect some code coverage/quality criteria (not the case today)
  • Documentation shall be initiated (M2/M3)



Tooling (the code we develop to test and integrate ONAP)

should not be very different than the other code even if it is not as critical as not part of the release

oparent docker ready (M2/M3)

java11 docker ready for consumption (M2/M3)





  • No labels