...
Topic | Discussion | ||||||||
---|---|---|---|---|---|---|---|---|---|
Calendar Entry | Calendar now open for editing ... but how? | ||||||||
R6 CCSDK-based Solution | Project as part of CCSDK ( Yuriy Malakov )
| ||||||||
R6 Frankfurt | In release requirements page: M4 March 5, 2020 Frankfurt Release Requirements (TSC has already approved Green status for U/C). CCSDK, SDN-C - Dan Timoney MVP (min viab. product) discussed on SDN-C call. Req not totally clear, schema model. Take what is in ConfigDB; finalize the Data Model approach.
| ||||||||
R7 Project Proposal | RunTime Config DB Project Proposal (Oct 25 2019) Project Proposal work to be done during R6. Project Proposal for R7. Presentation at Arch S/C and TSC during R6.
| ||||||||
R7 Separate Component |
Email from Dan Timoney My understanding from Sandeep was that this work was very much a stretch for Frankfurt. So, I’m okay with work starting in Frankfurt, as long as its structured so that it’s a separable component (i.e. as long as, if it’s not completed in Frankfurt, the platform is not fundamentally broken). I would NOT support creating a separate repository, since there is a fair amount of overhead involved in maintaining each repository on an ongoing basis – both machine and human resources. The Linux Foundation itself has been pushing back on the number of repositories the ONAP projects have and there is now a new approval process needed in order to add new ones. If a new repository is needed, then this team will need to convince me why no existing repository can be used AND will need to provide a resource who is willing to maintain that repository (i.e dealing with security vulnerabilities; policing code coverage ; doing release builds, etc). | ||||||||
...