Wiki

This discussion will take place on: Friday October 24, 7AM Pacific Time

• 1. Please join my meeting from your computer, tablet or smartphone. o https://global.gotomeeting.com/join/798898261

• 2. Use your microphone and speakers (VOIP) for audio. You'll sound best with a headset. You can also call in using your telephone. o United States (Long distance): +1 (872) 240-3312

Access Code: 798-898-261 Audio PIN: Shown after joining the session

Meeting Presentation call_to_continue_sr_planning_october_24_7am_pt

Meeting Minutes:

Attendees: Dave Lenrow (HP), Chris Price (Ericsson), Mike Lynch (Intel), Palani Chinnakannan (Cisco), Dave Neary (Red Hat), Ashiq Khan (Docomo), Bertrand (Docomo) – Have I missed anyone? -Mike

• Dave presented slides to frame our discussion
• Simultaneous Release Definition: SR is something that other projects, e.g. ODL, utilize. It’s the process by which multiple disparate projects agree to synchronize and converge development process, code freeze and agree on tests, etc, for a release. The process to produce a deliverable. We need to have that definition agreed but more especially have the process defined – that other projects can buy into and adhere to
• Palani: We need to deal with and comprehend sometimes volatile upstream projects…
• [Action Point]: Palani will work on defining a process as to how we manage patches in OPNFV in lieu of upstreaming, and how we move patches upstream, etc. Palani will set up a meeting early next week to move this forward
• We need to get some of the goodness/output of the lab testing activity into the SR process as well
• Need to decide on whether we have a strict release cadence (e.g. 6 months or whatever) or whether we want to have an ability to release at any time (continuous release capability). Note: many of the initial projects in our upstream list have strict release cadences.. Per Chris: ultimately we want to get to the point in OPNFV that we have a Continuous Release capability such that we can pull a release at any time. However we also need to abide by the OPNFV Board’s request to have a stable OPNFV release every 6 months. By the time of our first OPNFV release in 1H 2015, we may not have all the infrastructure in place to support that Continuous Release capability but over time we want that fully in place.
• We should only release projects that are part of the platform, not other pieces that are outside that scope
• We need a view of the Upstream project timelines so that we know what upstream cadences we need to adhere to, etc. Need also a view of what the project baseline is and the current set of stable releases available.
• Mike: to really get a full understanding of our release schedule for OPNFV R1.0, we need to look at both ends of the upstream project funnel: current stable releases but also the schedule for next stable releases. Then we need to look at the collaborative development projects we have in our list for approval at TSC and see which ones can realistically hit both the upstream schedule for new stable releases and the ambition milestone for OPNFV R1.0. We will need to make some quick decisions at TSC concerning current project proposals and which of them we can include in a 1H 2015 OPNFV stable release. Of course other project submissions can go ahead in parallel – and intersect a release post R1.0 (or as part of a Continuous Release process – if we have it in place).
• [Action Point]: Chris will start to map out the release cadences and versions of the relevant upstream projects we have chosen for the initial set of OPNFV projects
• Chris believes we need to be more aggressive in the timeline - need to determine what is our timeline for OPNFV first, then we need to see what we can achieve based on upstream project schedules
• Need to strike a balance between new stable releases of upstream projects and going with older revisions – we need to have a balance to ensure we also meet a regular release cadence of our own.
• Layers and offsets: need to consider where we have testing dependencies within the OPNFV platform testing (e.g. some testing can’t start before testing of another component has completed, etc). This needs careful consideration, and will likely consume a lot of effort. General integration testing for the platform as a whole needs to be carefully planned.
• [Action Point]: Dave will continue to build out the wiki page for SR with the latest information and status