Page Comparison

Self-commit exemption for PTLs

(by request from PTL meet)

Allow PTLs to +2 and merge their own commits

Why?

• PTL's are now burdened by the +2 rule when they need to make
  • immediate fixes - usually jenkins/sonar related
  • experiment with getting usually jenkins/sonar/release issues going
• 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

I was going to do a slide - but I find that a read-only way to put up editable content.

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 companies here) - I humbly advise reiterating pushing WIP ONAP work in public (not private)

ONAP is not a push/pull area where you pull a release, work in private then push your finished code as new-project/scope change.

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. Workarounds are made in private, issues start appearing in private because public has moved/fixed on. The fix: work only in public - throw out your internal wiki and JIRA system (keep it only for config etc...)

Case in point when we (Oracle) opensourced TopLink into EclipseLink (Hibernate peer) - we only worked in public

there was no internal for

http://bugs.eclipse.org/266912

We continue to schedule private meetings that reference internal wiki/jiras about public onap projects - this needs to be minimized - fix: always add onap-discuss to your meeting invite - a lot do.

Try to put as much generic content in public and reference it from your internal systems.

I have worked with 4 internal 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.

The best way to work in ONAP is to forget your internal JIRA/Confluence password.

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 - and we need to get paid to work in ONAP. 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