...
| Duration | Agenda Item | Requested by | Notes / Links |
|---|---|---|---|
| START RECORDING | |||
| 5 m | Housekeeping | ||
| 10 m | Release Status | ||
| 10 m | Integration Status | ||
| Known Vulnerability Analysis | Stephen terrill | ||
| 20 M | TSC Composition | ||
| 15 m | Subcommittee / Coordinator Update | Carried forward for 5 weeks | |
| 15 m | Versioning & API Documentation Guidelines | seeking TSC approval for Casablanca | |
| 5m | Self-commit exemption for PTLs (by request from PTL meet) | Allow PTLs to +2 and merge their own commits Why?
Discussed in PTL meet this monday - by consensus Original hardening of the commit rules was proposed by me on TSC 2018-03-15 - at the time a PTL exception was not fully discussed. | |
| 5m | SEC queries are not in public | I had 2 queries from the SEC last week on scope - one of them directly to my superiors in Amdocs. In the future scope should be discussed in either the wiki, onap-discuss, the weekly meeting of the project's under question (I host both OOM and Logging in question) or the ARC SC. In general we should do everything in public. | |
| 5m | Reiterate - ONAP first strategy VP's (I only have knowledge of 2 - mine + 1) need to address ONAP in secret work and help their internal teams move to working in ONAP first instead of treating ONAP like a pull/push area - where you get code from (work offine for a couple months) - then push your new code to. This seed code mentality is still happening in casablanca. | WIP projects/scope changes can be done directly in ONAP as they go - they do not need to be done in secret and uploaded to ONAP when completed. In my experience with 3 companies in ONAP - a lot of work - maybe more than in public - is done in private. Sometimes code is copied privately where it diverges from the original. We continue to schedule private meetings that reference internal wiki/jiras about public onap projects - this needs to be minimized. Try to put as much generic content in public and reference it from your internal systems. I have worked with 4 teams so far that work on ONAP or Acumos artifacts (but disconnected from the actual open source projects) - all of them have stated that their changes are not ready enough to put in public - The VP's need to let them know that they can work from scratch in public. Case in point: Acumos-ONAP collaboration is starting - but some private wiki content and code is still being reference from public facing meetings. I get asked to collaborate for 2 different companies - but one end of the collaboration is behind a firewall - public work should be in public on both ends. VPs: I understand that there is a need to fund opensource work now - as the services benefit is still in the future. That being said there is consequences of branching work - usually the public side misses out. My view is: if it does not exist in ONAP - than it does not exist - to paraphrase a librarian in SW2 | |
...