Open Transport Configuration & Control
Space shortcuts
Expand all   Collapse all
Child pages
  • TAPI Delivery Review Process - DRAFT
Skip to end of metadata
Go to start of metadata

Updated  

The content and scheduling of a TAPI release is described at TAPI Roadmap 2023 page.

Any major TAPI release (vX.Y) must be associated to a TAPI RIA version (vA.B)

The developmnent of TAPI RIA Requirements and Use Cases guides the development of TAPI model (from Requirements and Use Cases to Model).

When a meaningful/identified/consistent set of features have been consolidated in RIA discussions, an intermediate TAPI releases (v.X.Y.Z) can be delivered.

Process to be followed for the delivery of a TAPI Major Release

A pre-release major version is declared to be "ready for review" at a regular TAPI call.

It is required that at least the OTCC TST members provide a vote on the available voting page (e.g. TAPI Release v2.3.1 Approval):

  • Italo Busi

  • Weiqiang Cheng (remove?)

  • Thorsten Heinze (DMIP Lead)

  • Kam Lam (TSIM Lead)

  • Arturo Mayoral

  • Andrea Mazzini (TAPI Co-Lead)

  • Karthik Sethuraman (TAPI Co-Lead)

  • Martin Skorupski

  • Stephane St. Laurent (remove?)

  • Tracy van Brakle

  • Ricard Vilalta (remove?)

  • Ramon Casellas
  • Nigel Davis

This list shall be updated

The vote is extended to all contributors, where a contriburs is attending TAPI calls regularly (definition of "regularly").

The vote should be extended to all downstream consumers of TAPI.

The possible votes are yes, no and abstain. For approval, a certain percentage of yes votes shall be defined (e.g. the 1/3 of MEF).

  • The review period shall not exceed two full working weeks.
  • As a general rule, no further modifications are allowed during the review period.
    • During TAPI regular calls small fixes can be agreed and tracked in the voting page.
  • Deadline date for voting shall be specified in the TAPI call minutes and in the dedicated voting page.
  • Comments can be added to the voting page (once I find how to add comment box...)
    • A negative vote must be motivated by specific comment(s), otherwise will be considered as a "void vote".
  • The review period can end in only two ways:
    • Delivery is agreed: there are enough yes votes according to the rules.
    • Delivery is not agreed: all other cases.
      • The delivery release process must be repeated.
        • Explore "fast process" option.
        • Explore "deadlock avoidance" process, e.g. after two failed reviews reduce quorum, and/or dedicated vote to solve a conflict.

TAPI Model is composed by the following technology agnostic modules:

  1. TapiCommon
  2. TapiNotification
  3. TapiStreaming
  4. TapiFm
  5. TapiTopology
  6. TapiEquipment
  7. TapiPathComputation
  8. TapiVirtualNetwork
  9. TapiConnectivity
  10. TapiOam

And by the following technology specific modules:

  1. TapiDsr
  2. TapiEth
  3. TapiOdu
  4. TapiPhotonicMedia

Current editors of the model are listed in the Yang modules:

  • Ramon Casellas
  • Nigel Davis
  • Arturo Mayoral
  • Andrea Mazzini
  • Karthik Sethuraman

To split the review work, each editor is required to focus on a specific subset of the modules, which

  • will be informally agreed,
  • will include the modules subject of the modifications.