Page tree
Skip to end of metadata
Go to start of metadata

Logistics

Date and Time

  • 6 a.m. (PT) on Fridays

Conference Call (Zoom)

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/173830072

Or iPhone one-tap :
    US: +16465588656,,173830072# or +16699006833,,173830072# 
Or Telephone:
    Dial(for higher quality, dial a number based on your current location): 
        US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)
    Meeting ID: 173 830 072
    International numbers available: https://zoom.us/u/acZvdbE9P0

IRC

Meetings

January 4, 2018

Agenda

December 28, 2018 (Cancelled due to holidays)

December 21, 2018 (Cancelled due to holidays)

December 14, 2018

Agenda

Minutes

December 7, 2018

Agenda

Minutes

November 30, 2018

Agenda

November 23, 2018 (Cancelled)

November 16, 2018

Agenda

  • Conclude discussion about requirements for now.
  • Begin establishing process.

November 9, 2018

Agenda

  • Continue discussion about requirements
  • Working group chair

Minutes

November 2, 2018

Agenda

  • Continue discussion about requirements
  • Working group chair

Minutes

  • Reviewed emailed questions from Ramy and Harry H that pertain to release process.

October 26, 2018

Agenda

Minutes

October 19, 2018

Agenda

  • Working group chair
  • CD cadence and milestones
  • CD release artifacts

Minutes

  • Cadence and milestones
    • We will still have a twice yearly release, to help with project promotion and marketing 
    • The CD release model will server as meta releases throughout the cycle 
    • Release process should be lightweight for "official" and "intermediate" releases, as the current process is considered burdensome for some 
    • every 6 months take the "best" release and make that part of an OPNFV release 
    • Trevor Bramwell describes Jenkins release cycle - every 2 weeks plus major release every 12 weeks 
    • Trevor Bramwellsuggests that there should be two separate, independent, releases for CD and traditional release. 
      • Every 6 months, pick a previous CD release and "upgrade" it to LTS 
      • For the traditional release, choose a CD release, and promote that as the "big" release; 
        • Some additional testing/validation/collateral may be needed to package this big release.
      • How does a CD release get chosen as the "big"/official release? 
        • We need to define criteria for choosing an official release from the set of CD releases 
    • Trevor Bramwell suggests two levels of process: 1) individual project releases; and 2) OPNFV major releases 
    • Trevor Bramwell says define requirements first, then determine process 
    • What did we discuss and agree on at the last plugfest?
    • Release requirements need to be defined per type of project 
    • test projects need to be validated separately, so that the validation they provide is credible

October 12, 2018

Agenda

  • Working group purpose
  • Meeting logistics (time, frequency, etc.)
  • Chair selection
  • Discussion topics and priority

Minutes

  • Introduction and Purpose
    • David McBride discusses need for TSC level group to drive updates and changes to OPNFV release process
    • The RPWG will look at process at a high level, as opposed to the regular release meeting which deals with the day-to-day issues of executing the current release process
    • Important issues to be addressed:
      • CD process
      • Better accommodation of non-feature projects that do not deploy a scenario (e.g., test frameworks and tools)
  • Chair selection 
    • Group agrees that a community member should chair the group, following the initial startup period 
    • Mark Beierl suggests that if we can't find someone to commit to being the chair, then a fallback would be to rotate the chair among members of the working group. Emma Foley  agrees.
  • Discussion topics for upcoming meetings
    • continuous delivery
    • release timing for projects using CD model (
    • Mark Beierl suggests CI/CD releases should not have branches as we will not go back to old versions to fix a bug and release that as a branched version. 
      • CI/CD releases always move forward and new features along with bug fixes are always put on the new release. Only traditional release has bug fix branches 
    • how do we use test tools within CD process? Test tools need independent validation before they can be used to validatie features
    • Should different implementers of CD (e.g. XCI, Apex) follow a model (spec) so that they produce similar results for the same feature?  Or, should implementers follow their own design decisions with varying results for the same feature. 
    • some projects have dependency chains that may prevent them from participating in CD (e.g. ArmBand/Fuel depend upstream on Mirantis integration with openstack)
    • Release gates. How many? What are the requirements for each? 


  • No labels