thanks for the summary. Let’s remind ourselves, that in OPNFV we’re really 
trying to meet the needs of two different audiences: (1) User/consumer of a 
readily integrated NFV stack – as well as marketing operations (2) 
Developer/tester of an NFV stack. Audience #1 is mostly interested in 
stability, even if that means that things are released a little later (i.e. you 
build on long released components). Audience #2 is pushing the envelope and 
requires the ability to evolve/develop and integrate the latest set of 
components; once working they desire to release things to allow others to build 
on top; and move on/start over.

The current 1.0/2.0/3.0 was an effort to meet the needs of both audiences, i.e.

·       Have a “major” release.

·       Allow developers to release scenarios when they are ready and evolve, 
without too much of a maintenance burden.
This is also why we typically did not fix component versions for a release, but 
said: Based or ODL Boron or later.

I agree that releases are not free – especially the “major” release, because it 
comes with significant documentation and coordination needs. That said, it is 
mostly the “major” release with a lot of central coordination which creates 
efforts. Labeling and pushing an updated version of test results and 
documentation is relatively low effort – and can even be done by a scenario 
team. It does not even require central coordination. And our pipeline is now 
mature enough to do these things with low/moderate overhead.

So rather than move back in history and go back to a single release every 6 
months, which will make OPNFV a very inflexible organization for developers, I 
would strongly suggest that we rather consider evolving the current release 
process. IMHO we should be ready to have monthly micro-releases (scenario 
owners publish those scenarios which are “ready”, i.e. have docs ready and pass 
testing), and every 6 months we do a macro-release (with marketing/press 
announcement) which includes the set of scenarios which are “ready” by then. 
Macro-releases can be coupled to certain upstream component versions (as 
selection criteria for what is in/out of a macro release) – whereas 
micro-release would enjoy complete freedom.


Thanks, Frank

From: David McBride [mailto:dmcbr...@linuxfoundation.org]
Sent: Mittwoch, 15. Februar 2017 20:26
To: TECH-DISCUSS OPNFV <opnfv-tech-discuss@lists.opnfv.org>; 
Cc: Frank Brockners (fbrockne) <fbroc...@cisco.com>; Tapio Tallgren 
Subject: [release] E-release schedule


During the TSC call, yesterday, I took an action to start an email discussion 
about the schedule for the 

Specifically, I suggested that we just plan for a single release, rather than 
three releases, as we've done in the past.  Then, when the release date 
approaches, we evaluate whether we need a point release, then schedule it at 
that time.


  *   Scheduling three releases has created a lot of confusion with the project 
teams  The purpose of the three releases is to give project teams time to debug 
and fix scenarios that are not ready for 1.0.  They are not separate 
development timelines with separate release milestones.  However, many believe 
that it isn't necessary to meet release milestones, because they will simply 
shift to the 2.0 or 3.0 release.
  *   In the past two releases, the new content released in 2.0 has been 
minimal.  For example, for Colorado 2.0, just two new scenarios were released.  
Human nature is such that, given the opportunity for a later deadline, many 
will take it.
  *   Releases are not free.  In addition to the overhead required for 
labeling, creating ISOs, and updating documentation, projects that released in 
previous releases, are required to update their code for subsequent releases to 
resolve any issues, even if they weren't intending to do any additional work on 
that major release.  For example, let's say that a project releases in Danube 
1.0, they're satisfied with their effort, so they shift their focus to the 
E-release.  However, changes after 1.0 break their scenario.  So, suddenly, 
they find themselves working on Danube 2.0, even though they aren't releasing 
any new scenarios. This process repeats for Danube 3.0.
During the TSC call, it was suggested that a 2.0 or 3.0 release provides an 
opportunity to integrate a late release of a major upstream component (e.g. 
ODL).  However, this is counter to our previous agreement not to change major 
upstream components after the 1.0 release.  Unfortunately, this happened in 
Colorado and created significant disruption, including a slip in the 2.0 

Per our discussion on Tuesday, I've created a wiki 
page<https://wiki.opnfv.org/display/SWREL/E-Release+Schedule+discussion> to 
capture pros and cons of various schedule options.  Feel free to edit it and 
add your thoughts.


David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018<tel:%2B1.805.276.8018>
Email/Google Talk: 
Skype: davidjmcbride1
IRC: dmcbride
opnfv-tech-discuss mailing list

Reply via email to