I don't see any issue here.  Colorado 1.0 is set to use Beryllium, which is 
already released.  Even the scenarios that require Boron (FDS/SFC) do not 
require ODL HA, and we already have Boron RC builds that work.  ODL HA is known 
to be buggy, so at least in Apex we don't enable it.

Tim Rozet
Red Hat SDN Team

----- Original Message -----
From: "David McBride" <dmcbr...@linuxfoundation.org>
To: "Christopher Price" <chrispric...@gmail.com>
Cc: opnfv-project-le...@lists.opnfv.org, "TECH-DISCUSS OPNFV" 
<opnfv-tech-discuss@lists.opnfv.org>
Sent: Friday, September 2, 2016 1:24:13 PM
Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][hackfest]     
Release Milestone Review presentation

Chris, 

As I understand it, some projects are planning to use Beryllium. Do we know if 
the blockers effect both Beryllium and Boron, or is it just Boron? If it's just 
Boron, then the projects that depend on Beryllium could release at Colorado 
1.0, while the projects that depend on Boron could release at Colorado 2.0 or 
3.0. 

In fact, I heard from Greg Elkinbard, yesterday, who said that scenarios 
running on Fuel will be transitioning to Boron for Colorado 2.0. 

David 

On Fri, Sep 2, 2016 at 2:36 AM, Christopher Price < chrispric...@gmail.com > 
wrote: 





Hi Folks, 



Hard rules can be hard to find in an environment like ours. J 

I think we need in some cases to have “expectations” and allow the release 
project to evaluate how those “expectations” are met. In other cases, the 
“expectations” are pretty straightforward. 



We need to somehow articulate our developmental and testing needs while making 
room for the fact that we are not in complete control of our dependencies. 





For example, I was on the OpenDaylight TSC call yesterday and they are 
considering a potential small delay in their release dates due to some 
“blockers” on OpenFlowPlugin and NetVirt specifically for HA. These blockers 
impact us directly. These issues may further result in a delay for the ODL 
release version to be built and made available. 



We have 2 options to take here: 

1) Take an older version of ODL, that we know has issues directly related to 
our use of ODL. 
(carry these blocking bugs through Colorado 1.0) 

2) Iterate our version and take in the release that fixes the blocking bugs. 



This relates very much to the fact that resolving issues in our own 
troubleshooting is for the most part dependent on upstream communities being 
able to resolve issues we identify. (or finding workarounds) 



In my mind it is very hard to find a “rule” we can apply here as each situation 
is different. 

For this example I believe the best way to solve this would be to have a phase 
at “code freeze” where we discuss issues and manage the patches that we allow 
into the release. Maybe this is something to consider for D release where David 
could arrange a small team that facilitates these decisions after code freeze. 




For now, David has only one recourse and that is to ask the TSC for a decision 
on patches and version stepping. 




I do hope however that we can work together for D to continue to drive for a 
methodology that keeps us from a massive rush in the last months but enables 
fast and efficient integration of new code… 



/ Chris 




From: < opnfv-tech-discuss-boun...@lists.opnfv.org > on behalf of Ulrich Kleber 
< ulrich.kle...@huawei.com > 
Date: Friday 2 September 2016 at 11:09 
To: David McBride < dmcbr...@linuxfoundation.org >, opnfv-project-leads < 
opnfv-project-le...@lists.opnfv.org >, TECH-DISCUSS OPNFV < 
opnfv-tech-discuss@lists.opnfv.org > 
Subject: Re: [opnfv-tech-discuss] [release][hackfest] Release Milestone Review 
presentation 





Hi David, 

I remember we had some issues understanding the meaning of the “feature freeze” 
milestone. 

While reading again the lessons learned, I remembered that in former projects I 
worked on, 

we called that milestone “code complete”. These two words for me quickly 
associate that I should 

have now created my code, but would still be able to do some changes for fixing 
bugs. 

Just an idea. Maybe give it a thought.... 

Cheers, 

Uli 




From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto: 
opnfv-tech-discuss-boun...@lists.opnfv.org ] On Behalf Of David McBride 
Sent: Wednesday, 24 August, 2016 20:55 
To: opnfv-project-le...@lists.opnfv.org ; TECH-DISCUSS OPNFV 
Subject: [opnfv-tech-discuss] [release][hackfest] Release Milestone Review 
presentation 





Thanks to those of you that attended my presentation at the OPNFV Q3 Hackfest. 
The questions and feedback I received are welcome and very helpful. 





I've posted the presentation on the wiki . Let me know if you have additional 
questions or comments. 





David 





-- 


David McBride 


Release Manager, OPNFV 


Mobile: +1.805.276.8018 


Email/Google Talk: dmcbr...@linuxfoundation.org 


Skype: davidjmcbride1 


IRC: dmcbride 


_______________________________________________ opnfv-tech-discuss mailing list 
opnfv-tech-discuss@lists.opnfv.org 
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss 



-- 
David McBride 
Release Manager, OPNFV 
Mobile: +1.805.276.8018 
Email/Google Talk: dmcbr...@linuxfoundation.org 
Skype: davidjmcbride1 
IRC: dmcbride 

_______________________________________________
opnfv-project-leads mailing list
opnfv-project-le...@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-project-leads
_______________________________________________
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Reply via email to