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 »

Topics, Notes, and Follow-Up Tasks

Backlog IssuesNotes / StatusFollow-up
Release / Branching Strategy
  • Amsterdam doc project branch created and tracking updates in any other repo providing documentation  that has an Amsterdam branch. For those that did not have an Amsterdam branch, we are using head of the master branch as of ~11/24 4pm EST.
  • Project repos that still need to be tagged:
  • Where Amsterdam changes are expected and should be automatically published when merged, an Amsterdam branch may be created.
  • Both master and amsterdam are being published at read the docs.  The default when someone enter http://docs.onap.org is master and the the developer wiki download link currently points to master.    Should we change this?


  • Each PTL committer for the repos list in column 2, to identify the hash and create a release branch "amsterdam".
  • Sync up the doc project amsterdam branch submodule references with created amsterdam branches,  DOC-210 - Getting issue details... STATUS
  • Switch DW download link to RTD amsterdam when branches above are completed Rich Bennett   



Naming Standard

SDC and Modeling are using 1.1.0 - is this acceptable - should we just have one naming convention?

Questions to be answered whenever the TSC votes to create a named release:

  1. where do residual improvements go for Amsterdam
  2. where do major new changes go for Beijing
  3. when do we start merging the # 2 changes to master.

We can probably accommodate different names for (#1) and/or some delay to starting #2 as long as everyone has the same view a timeline.   Is there isn’t a better way use tags, eg

  1. on the RC dates…. A  Release Candidate tag is placed on every repo within a very short time by LF (< 1 hour),
  2. tests proceed using only tagged candidate versions
  3. If major tests fail, fix and goto the next RC (step 1)
  4. Declare a release from the last RC tags
  5. if / when any change is needed, a branch is created from the last RC tag

Topic for lessons learned at Santa Clara F2F? gg2147@att.com

  • Forward these issue notes to Gildas for discussion


Touch base with OpenNFV / other Open Source projects?

Test Lab

Create for HEAT and OOM:  Ticket OPENLABS-75 - Getting issue details... STATUS


New ProjectsSee:  Doc Work Plan for Beijing (Release 2)



  • No labels