TSC 2018-05-24 Meeting Agenda

Self-commit exemption for PTLs

(by request from PTL meet)

Allow PTLs to +2 and merge their own commits

Why?

• weekend/TZ 2nd committer not available
• need to triage jenkins issues without a 12h+ turnaround on each commit
  
  

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.

I had 2 queries from the SEC last week on scope (one major, one minor) - one of them directly to my superiors in Amdocs - without including me.

There are a couple issues with this

• queries to a PTL should be done in public - benefit the project/community
• queries about a PTL should include the PTL
• queries about a PTL should not be just between 2 companies of ONAP
• we have a scope problem here - in my opinion any work done for the betterment of ONAP should be encouraged - all work is complementary.
• The SEC only goes after those it knows about or ignores other scope violations
• We need to act more like one project and less like a cubicle farm of multiple loosely coupled open source projects

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.

I made up the SEC acronym

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 for either company depending on the project - 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 are 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