Date
Duration 90 minutes
Discussion items
| Duration | Agenda Item | Requested by | Notes / Links |
|---|---|---|---|
| START RECORDING | |||
| 5 m | Housekeeping | ||
| 15 m | CLA Process | Phil Robb | |
| 10 m | Release Status | ||
| 10 m | Integration Status | ||
| 10 m | VNF package security recomendation from seccom (for endorsement) | Stephen Terrill | |
| 10 m | Follow-up on project definition review | Stephen Terrill | 2018-01-25 TSC approved to initiate a review of the project definitions - Chair/LF took action to comeback with a proposal on how. Looking forward to the proposal update. |
| 10 min | CII Badging program follow-up | Stephen Terrill | |
| 15 m | Subcommittee / Coordinator Update | as per rotation schedule | |
| 5 m | Self merging code no review by a 2nd developer no review by a 2nd company merges that occur between 1 and 59 min after initial commit | We have a serious issue where committers are merging their own code - with no review or oversight. I might be missing something but this automated check put into place in oct has no effect https://lists.onap.org/pipermail/onap-discuss/2017-October/005982.html https://lists.onap.org/pipermail/onap-discuss/2017-October/005832.html I have tried to keep this low level - but if we are held to rigid deadlines like these teams - we need a level playfield and not an effective 2 tier system. Analogy 1 those that drive in either the left or right lane those that just ignore the yellow line and create 3 lanes out of 2 Analogy 2 Those that use the exit lane on the highway only to exit Those that use the exit lane as an evolutionary advantage to jump the queue and merge back in at a higher position Q) are those of us following the rules actually doing the right thing in the long run? projects I have run into are integration, vfc, sdc - I am not targetting these projects - as these are just the ones I have run into so far This is wrong for several reasons and several of us have raised this in the discuss groups for a while reviews are meant to share changes reviews can be incremental so that other developers can consume work in progress reviews catch potential issues with integrating the change inside and outside the particular onap component. If we don't enforce the 2 rules that the rest of us are bound by - then those that follow the rules are in a significant disadvantage - for example I would like to merge a script - I need to put it through rigourous review by 5-10 developers over the course of a couple days - If i am working on parallel work that is on top of this commit in progress - then I need to resolve merge conflicts later - this all takes time - time that we could put to working on release details/artifacts rule 2 - second company - ideally we collaborate between organizations this way For the developers that just merge their own code and skip both the rules - they can have very high throughput. Exceptions: there have been some when critical fixes needed to get in to restore the build (we don't have proper CD E2E integration testing yet) - perhaps even these exceptions should not occur. some more history on this ongoing issue https://lists.onap.org/pipermail/onap-discuss/2018-February/008068.html https://lists.onap.org/pipermail/onap-tsc/2017-May/002341.html A good random example of following proper procedure https://lists.onap.org/pipermail/onap-sdnc/2017-August/000052.html | |
| 5m | docker hub nexus3 repos are inconsistent | docker image names are different between our repos. This is causing a problem when swapping out the repo URL - we need special handling for particular projects example: POLICY-674 - Getting issue details... STATUS policy-db for nexus3 | |