Re: [onap-tsc] Enforcing an "Upstream first" approach to ONAP

[Aayush.Bhatnagar]

I tend to agree with Lusheng and Dan.

If the size of the contribution is more than a certain limit, we can provide 
guidelines for enabling easier code review. Some suggestions are provided here -

1. Accompany the contribution with UML class diagrams to help structure the 
code review.

2. Contributor can organize a workshop on zoom to walk through the details 
before the contribution can be independently reviewed.

This can be done selectively for large code contributions, so that we strike a 
balance.

Regards

Aayush




On 4 August 2017 at 21:24:38 IST, TIMONEY, DAN  wrote:

All,



I wanted to second Lusheng’s excellent comments below, and add perhaps a bit 
more.



I think it’s important to bear in mind that some of the code that is 
contributed might not be entirely new.  For example, much of the seed code that 
we submitted for openecomp was existing code that we had developed and used 
internally within AT and then open sourced.   It is likely that we’ll come 
across similar examples as ONAP continues to evolve, where one company or 
another finds that they have existing code that can be integrated into ONAP 
that they would like to contribute.   So, while we absolutely should encourage 
developers to add code in small increments as they’re working (upstream first) 
but we should also not ask them to expend extra effort to break up 
contributions they’d like to make to meet some imposed limitation on number of 
lines.   Instead, perhaps there is some other process that should be followed 
for such commits (e.g. some comments within the commit message indicating this 
code is in use today by company X and is being contributed to ONAP?).. I’m sure 
other open source projects have had similar block commits, so it would be good 
to hear how other projects handle those types of contributions.



Dan



Dan Timoney

Principal Technical Staff Member

AT

Email : dtimo...@att.com

Office : +1 (732) 420-3226

Mobile : +1 (201) 960-1211

200 S Laurel Ave, Rm E2-2A03

Middletown, NJ 08873



From:  on behalf of "JI, LUSHENG" 

Date: Friday, August 4, 2017 at 1:43 AM
To: "onap-tsc@lists.onap.org" 
Subject: Re: [onap-tsc] Enforcing an "Upstream first" approach to ONAP



***Security Advisory: This Message Originated Outside of AT ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.

Dear TSC and ONAP community,



As I am reading through this thread, I can certainly appreciate David’s good 
intention behind the suggestion.  Perhaps this is a minority opinion here, but 
as a PTL and committer I have to say I am also concerned about “enforcing” 
things such as hard limit on submission LOC.



  1.  Contributions come in the shapes that they are in.  Some large some 
small.  Putting a submission size limit will not change that, but it would 
impact the integrity of large contributions though.  Say someone wants to 
contribute a new complex function but LOC too large, it is not like he would be 
able to break this one large contribution into several smaller contributions.  
The more likely outcome is that he will simply break the contribution into 
several smaller commits, each smaller than the LOC limit but only fragment of 
the original contribution file tree.  This would make committer’s job much 
harder because he now must review ALL of these commits together, equal amount 
of LOC, and spread in multiple submissions.  Individual commits like these 
cannot be reviewed individually effectively because it is difficult to assess 
its value to the whole project, without mentioning that individual submission 
may even break the CICD and testing of the project.
  2.  The “commit small commit often” practice of devops really relies on the 
rich support of features and branches of git.  We essentially have ONLY ONE 
branch, the master.  This is the key reason for why I am not sure we should 
follow the devops manual to a tee here.  None of those sophisticated branching 
workflows is applicable here.  ONAP gerrit is not best suited for being used as 
dev repo.  With this limitation, I would much prefer to have the head of master 
branch relatively clean and stable, only advanced by good quality, tested, and 
self-contained contributions, not by work-in-progress fragments.
  3.  Large submission does not necessarily equal to behind-door development.  
Gitlab is cheap.  Self-formed herds, even individual ONAP projects, can set up 
their own git server and apply all fancy workflows there, then make the whole 
contribution to ONAP when they are ready.  I actually believe this is more 
community based development.
  4.  Studies show that there is a loglog relationship between number of 
submissions and submission sizes for open source commits.  Large submissions do 
happen, but are rare.  We only see more of those now because we are pre-R1, 
many contributions are ports from 

Re: [onap-tsc] More Help For Adding Committers

[Haiby, Ranny (Nokia - US/San Jose USA)]

It seems like Confluence is a supported source for Bitergia (It is listed here 
under “supported tools”: https://www.bitergia.com/products/dashboards/)

So it should be possible to collect stats like:

  *   Wiki Page creations
  *   Page edits
  *   Comments
  *   File uploads

Ranny.


From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Gary Wu
Sent: Friday, August 18, 2017 1:30 PM
To: Kenny Paul ; Williams, Marcus 

Cc: onap-tsc 
Subject: Re: [onap-tsc] More Help For Adding Committers

Wiki/Confluence stats are not currently being reported.
Gerrit integration should also count reviews/comments.

Not sure if there is anything we can do to automate analytics on meeting 
participation.

Thanks,
Gary


From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Kenny Paul
Sent: Friday, August 18, 2017 1:01 PM
To: Williams, Marcus 
>
Cc: onap-tsc >
Subject: Re: [onap-tsc] More Help For Adding Committers

Hi Marcus,
Can you provide examples of you you feel is missing?

Best Regards,
-kenny

Kenny Paul,  Technical Program Manager
kp...@linuxfoundation.org
510.766.5945

On Aug 18, 2017, at 12:54 PM, Williams, Marcus 
> wrote:

FYI – Are we doing our own implementation of Bitergia? 
https://onap.biterg.io

The above info set seems to be missing some of the info we’d need to monitor 
metrics under discussion.

Also, completely agree with Pam’s point. +2

Thanks,
Marcus Williams
IRC @ mgkwill
Network Software Engineer
Intel Corp. - DataCenter Network Solutions Group

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Gary Wu
Sent: Friday, August 18, 2017 11:30 AM
To: DRAGOSH, PAMELA L (PAM) 
>; Kenny Paul 
>; Ed Warnicke 
>
Cc: onap-tsc >
Subject: Re: [onap-tsc] More Help For Adding Committers

Ideally all these metrics can be provided by Bitergia once we get it 
implemented?

Thanks,
Gary

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of DRAGOSH, PAMELA L (PAM)
Sent: Friday, August 18, 2017 5:14 AM
To: Kenny Paul >; 
Ed Warnicke >
Cc: onap-tsc >
Subject: Re: [onap-tsc] More Help For Adding Committers

Hey Kenny,

This is great thanks.

As a PTL, I personally feel it is important that committers aren’t just doing 
gerrit commits. But also show meritocracy in the following activities:
•actively participate in Weekly meetings
•respond to onap-discuss questions for that project
•actively help develop wiki information and respond to comments on 
wiki’s
•participate in gerrit reviews not just a submitter, but also review 
other submissions
•actively work with the PTL and other committers with planning for 
sprints, milestones, JIRA

All these items are just as important as someone who simply submits code, they 
ensure a healthy working team.

Thanks,

Pam Dragosh


From: > 
on behalf of Kenny Paul 
>
Date: Friday, August 18, 2017 at 2:11 AM
To: Ed Warnicke >
Cc: onap-tsc >
Subject: Re: [onap-tsc] More Help For Adding Committers

Hi Ed,
From the template:

Link(s) demonstrating the Contributor's established history of meritocratic 
contributions to the project:
(Typically this would be in the form of a gerrit query)


So assuming that the template is followed then, yes, that information should be 
provided :-)


Best Regards,
-kenny

Kenny Paul,  Technical Program Manager
kp...@linuxfoundation.org
510.766.5945

On Aug 17, 2017, at 6:48 PM, Ed Warnicke 
> wrote:

Could we add the history of meritocratic contribution via a link to a gerrit 
query for the proposed committers contributions to the repos of the project?

Ed

On Thu, Aug 17, 2017 at 6:40 PM, Kenny Paul 
> wrote:
In a further effort to both ease frustration of the PTLs and address general 
scalability 

Re: [onap-tsc] More Help For Adding Committers

[Kenny Paul]

Hi Marcus,
Can you provide examples of you you feel is missing?

Best Regards, 
-kenny

Kenny Paul,  Technical Program Manager
kp...@linuxfoundation.org
510.766.5945

> On Aug 18, 2017, at 12:54 PM, Williams, Marcus  
> wrote:
> 
> FYI – Are we doing our own implementation of Bitergia? https://onap.biterg.io 
> 
>  
> The above info set seems to be missing some of the info we’d need to monitor 
> metrics under discussion.
>  
> Also, completely agree with Pam’s point. +2
>  
> Thanks,
> Marcus Williams
> IRC @ mgkwill
> Network Software Engineer
> Intel Corp. - DataCenter Network Solutions Group
>  
>  <>From: onap-tsc-boun...@lists.onap.org 
>  
> [mailto:onap-tsc-boun...@lists.onap.org 
> ] On Behalf Of Gary Wu
> Sent: Friday, August 18, 2017 11:30 AM
> To: DRAGOSH, PAMELA L (PAM)  >; Kenny Paul  >; Ed Warnicke  >
> Cc: onap-tsc >
> Subject: Re: [onap-tsc] More Help For Adding Committers
>  
> Ideally all these metrics can be provided by Bitergia once we get it 
> implemented?
> 
> Thanks,
> Gary
>  
> From: onap-tsc-boun...@lists.onap.org 
>  
> [mailto:onap-tsc-boun...@lists.onap.org 
> ] On Behalf Of DRAGOSH, PAMELA L (PAM)
> Sent: Friday, August 18, 2017 5:14 AM
> To: Kenny Paul  >; Ed Warnicke  >
> Cc: onap-tsc >
> Subject: Re: [onap-tsc] More Help For Adding Committers
>  
> Hey Kenny,
>  
> This is great thanks.
>  
> As a PTL, I personally feel it is important that committers aren’t just doing 
> gerrit commits. But also show meritocracy in the following activities:
> ·actively participate in Weekly meetings
> ·respond to onap-discuss questions for that project
> ·actively help develop wiki information and respond to comments on 
> wiki’s
> ·participate in gerrit reviews not just a submitter, but also review 
> other submissions
> ·actively work with the PTL and other committers with planning for 
> sprints, milestones, JIRA
>  
> All these items are just as important as someone who simply submits code, 
> they ensure a healthy working team.
>  
> Thanks,
>  
> Pam Dragosh
>  
>  
> From:  > on behalf of Kenny Paul 
> >
> Date: Friday, August 18, 2017 at 2:11 AM
> To: Ed Warnicke >
> Cc: onap-tsc >
> Subject: Re: [onap-tsc] More Help For Adding Committers
>  
> Hi Ed, 
> From the template: 
>  
> Link(s) demonstrating the Contributor's established history of meritocratic 
> contributions to the project: 
> (Typically this would be in the form of a gerrit query)
>  
>  
> So assuming that the template is followed then, yes, that information should 
> be provided :-)
>  
>  
> Best Regards, 
> -kenny
> 
> Kenny Paul,  Technical Program Manager
> kp...@linuxfoundation.org 
> 510.766.5945
>  
> On Aug 17, 2017, at 6:48 PM, Ed Warnicke  > wrote:
>  
> Could we add the history of meritocratic contribution via a link to a gerrit 
> query for the proposed committers contributions to the repos of the project?
>  
> Ed
>  
> On Thu, Aug 17, 2017 at 6:40 PM, Kenny Paul  > wrote:
> In a further effort to both ease frustration of the PTLs and address general 
> scalability concerns, I have created a template for adding new Committers to 
> an ONAP project.
> This template can be found by going to the Adding/Removing Committers to a 
> Project 
> 
>  page found under the Developer Best Practices 
> 
>  section of the wiki.
>  
> The members of the TSC are closely scrutinizing these types of requests. If 
> you have a Contributor that 

Re: [onap-tsc] More Help For Adding Committers

[Kenny Paul]

Bitergia was implemented last week. https://onap.biterg.io 


https://lists.onap.org/pipermail/onap-discuss/2017-August/003139.html 




Best Regards, 
-kenny

Kenny Paul,  Technical Program Manager
kp...@linuxfoundation.org
510.766.5945

> On Aug 18, 2017, at 11:29 AM, Gary Wu  wrote:
> 
> Ideally all these metrics can be provided by Bitergia once we get it 
> implemented?
> 
> Thanks,
> Gary
>  
> From: onap-tsc-boun...@lists.onap.org 
>  
> [mailto:onap-tsc-boun...@lists.onap.org 
> ] On Behalf Of DRAGOSH, PAMELA L (PAM)
> Sent: Friday, August 18, 2017 5:14 AM
> To: Kenny Paul  >; Ed Warnicke  >
> Cc: onap-tsc >
> Subject: Re: [onap-tsc] More Help For Adding Committers
>  
> Hey Kenny,
>  
> This is great thanks.
>  
> As a PTL, I personally feel it is important that committers aren’t just doing 
> gerrit commits. But also show meritocracy in the following activities:
> · actively participate in Weekly meetings
> · respond to onap-discuss questions for that project
> · actively help develop wiki information and respond to comments on 
> wiki’s
> · participate in gerrit reviews not just a submitter, but also review 
> other submissions
> · actively work with the PTL and other committers with planning for 
> sprints, milestones, JIRA
>  
> All these items are just as important as someone who simply submits code, 
> they ensure a healthy working team.
>  
> Thanks,
>  
> Pam Dragosh
>  
>  
> From:  > on behalf of Kenny Paul 
> >
> Date: Friday, August 18, 2017 at 2:11 AM
> To: Ed Warnicke >
> Cc: onap-tsc >
> Subject: Re: [onap-tsc] More Help For Adding Committers
>  
> Hi Ed, 
> From the template: 
>  
> Link(s) demonstrating the Contributor's established history of meritocratic 
> contributions to the project: 
> (Typically this would be in the form of a gerrit query)
>  
>  
> So assuming that the template is followed then, yes, that information should 
> be provided :-)
>  
>  
> Best Regards, 
> -kenny
> 
> Kenny Paul,  Technical Program Manager
> kp...@linuxfoundation.org 
> 510.766.5945
>  
> On Aug 17, 2017, at 6:48 PM, Ed Warnicke  > wrote:
>  
> Could we add the history of meritocratic contribution via a link to a gerrit 
> query for the proposed committers contributions to the repos of the project?
>  
> Ed
>  
> On Thu, Aug 17, 2017 at 6:40 PM, Kenny Paul  > wrote:
> In a further effort to both ease frustration of the PTLs and address general 
> scalability concerns, I have created a template for adding new Committers to 
> an ONAP project.
> This template can be found by going to the Adding/Removing Committers to a 
> Project 
> 
>  page found under the Developer Best Practices 
> 
>  section of the wiki.
>  
> The members of the TSC are closely scrutinizing these types of requests. If 
> you have a Contributor that has earned the right to be a Committer, and you 
> have not already received a direct email from me indicating that your request 
> has been submitted to the TSC for approval, I strongly recommend that you 
> make use of the template and follow the process it outlines.
>  
> Hopefully this should make things run a bit smoother for all.
>  
> Please let me know if you have any questions.
>  
> Best Regards, 
> -kenny
> 
> Kenny Paul,  Technical Program Manager
> kp...@linuxfoundation.org 
> 510.766.5945 
>  
> 
> ___
> ONAP-TSC mailing list
> ONAP-TSC@lists.onap.org 
> https://lists.onap.org/mailman/listinfo/onap-tsc 
> 

Re: [onap-tsc] More Help For Adding Committers

[Williams, Marcus]

FYI – Are we doing our own implementation of Bitergia? https://onap.biterg.io

The above info set seems to be missing some of the info we’d need to monitor 
metrics under discussion.

Also, completely agree with Pam’s point. +2

Thanks,
Marcus Williams
IRC @ mgkwill
Network Software Engineer
Intel Corp. - DataCenter Network Solutions Group

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Gary Wu
Sent: Friday, August 18, 2017 11:30 AM
To: DRAGOSH, PAMELA L (PAM) ; Kenny Paul 
; Ed Warnicke 
Cc: onap-tsc 
Subject: Re: [onap-tsc] More Help For Adding Committers

Ideally all these metrics can be provided by Bitergia once we get it 
implemented?

Thanks,
Gary

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of DRAGOSH, PAMELA L (PAM)
Sent: Friday, August 18, 2017 5:14 AM
To: Kenny Paul >; 
Ed Warnicke >
Cc: onap-tsc >
Subject: Re: [onap-tsc] More Help For Adding Committers

Hey Kenny,

This is great thanks.

As a PTL, I personally feel it is important that committers aren’t just doing 
gerrit commits. But also show meritocracy in the following activities:

·actively participate in Weekly meetings

·respond to onap-discuss questions for that project

·actively help develop wiki information and respond to comments on 
wiki’s

·participate in gerrit reviews not just a submitter, but also review 
other submissions

·actively work with the PTL and other committers with planning for 
sprints, milestones, JIRA

All these items are just as important as someone who simply submits code, they 
ensure a healthy working team.

Thanks,

Pam Dragosh


From: > 
on behalf of Kenny Paul 
>
Date: Friday, August 18, 2017 at 2:11 AM
To: Ed Warnicke >
Cc: onap-tsc >
Subject: Re: [onap-tsc] More Help For Adding Committers

Hi Ed,
From the template:

Link(s) demonstrating the Contributor's established history of meritocratic 
contributions to the project:
(Typically this would be in the form of a gerrit query)


So assuming that the template is followed then, yes, that information should be 
provided :-)


Best Regards,
-kenny

Kenny Paul,  Technical Program Manager
kp...@linuxfoundation.org
510.766.5945

On Aug 17, 2017, at 6:48 PM, Ed Warnicke 
> wrote:

Could we add the history of meritocratic contribution via a link to a gerrit 
query for the proposed committers contributions to the repos of the project?

Ed

On Thu, Aug 17, 2017 at 6:40 PM, Kenny Paul 
> wrote:
In a further effort to both ease frustration of the PTLs and address general 
scalability concerns, I have created a template for adding new Committers to an 
ONAP project.
This template can be found by going to the Adding/Removing Committers to a 
Project
 page found under the Developer Best 
Practices
 section of the wiki.

The members of the TSC are closely scrutinizing these types of requests. If you 
have a Contributor that has earned the right to be a Committer, and you have 
not already received a direct email from me indicating that your request has 
been submitted to the TSC for approval, I strongly recommend that you make use 
of the template and follow the process it outlines.

Hopefully this should make things run a bit smoother for all.

Please let me know if you have any questions.

Best Regards,
-kenny

Kenny Paul,  Technical Program Manager
kp...@linuxfoundation.org
510.766.5945


___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org

Re: [onap-tsc] More Help For Adding Committers

[Gary Wu]

Ideally all these metrics can be provided by Bitergia once we get it 
implemented?

Thanks,
Gary

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of DRAGOSH, PAMELA L (PAM)
Sent: Friday, August 18, 2017 5:14 AM
To: Kenny Paul ; Ed Warnicke 
Cc: onap-tsc 
Subject: Re: [onap-tsc] More Help For Adding Committers

Hey Kenny,

This is great thanks.

As a PTL, I personally feel it is important that committers aren’t just doing 
gerrit commits. But also show meritocracy in the following activities:

· actively participate in Weekly meetings

· respond to onap-discuss questions for that project

· actively help develop wiki information and respond to comments on 
wiki’s

· participate in gerrit reviews not just a submitter, but also review 
other submissions

· actively work with the PTL and other committers with planning for 
sprints, milestones, JIRA

All these items are just as important as someone who simply submits code, they 
ensure a healthy working team.

Thanks,

Pam Dragosh


From: > 
on behalf of Kenny Paul 
>
Date: Friday, August 18, 2017 at 2:11 AM
To: Ed Warnicke >
Cc: onap-tsc >
Subject: Re: [onap-tsc] More Help For Adding Committers

Hi Ed,
From the template:

Link(s) demonstrating the Contributor's established history of meritocratic 
contributions to the project:
(Typically this would be in the form of a gerrit query)


So assuming that the template is followed then, yes, that information should be 
provided :-)


Best Regards,
-kenny

Kenny Paul,  Technical Program Manager
kp...@linuxfoundation.org
510.766.5945

On Aug 17, 2017, at 6:48 PM, Ed Warnicke 
> wrote:

Could we add the history of meritocratic contribution via a link to a gerrit 
query for the proposed committers contributions to the repos of the project?

Ed

On Thu, Aug 17, 2017 at 6:40 PM, Kenny Paul 
> wrote:
In a further effort to both ease frustration of the PTLs and address general 
scalability concerns, I have created a template for adding new Committers to an 
ONAP project.
This template can be found by going to the Adding/Removing Committers to a 
Project
 page found under the Developer Best 
Practices
 section of the wiki.

The members of the TSC are closely scrutinizing these types of requests. If you 
have a Contributor that has earned the right to be a Committer, and you have 
not already received a direct email from me indicating that your request has 
been submitted to the TSC for approval, I strongly recommend that you make use 
of the template and follow the process it outlines.

Hopefully this should make things run a bit smoother for all.

Please let me know if you have any questions.

Best Regards,
-kenny

Kenny Paul,  Technical Program Manager
kp...@linuxfoundation.org
510.766.5945


___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc


___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] R2 use cases planning

[Sabater, Susana, Vodafone Spain]

Hi Alla, all,

I think there has been a response from Rajesh on the topic of 5G slicing. I 
must say I am in favour of seeing it since that will be a clear proof that ONAP 
platform works for different use cases, and actually works for concurrent ones.

Let me explain:
An operator may host in its network both mobile and fixed services and then 
dedicate a slice to mobile services and a different slice to fixed services. 
Still, the platform will have to define the two services and manage them 
concurrently.
So, a way to work out the capabilities of ONAP is using slicing for VoLTE and 
vCPE: create, terminate, scale the slices, handle performance and faults from 
the different services, etc, and maybe be able to share VNFs between several 
slices.

All in all, I believe slicing is a use case that could be worth considering, 
even if no new use cases are developed (although I believe both SD-WAN and 
enterprise vCPE are also important to handle).

My 2 cents.

Cheers
/Susana


From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Alla Goldner
Sent: Friday, August 18, 2017 1:28 PM
To: Vladimir Yanover (vyanover) ; Jason Hunt 

Cc: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] R2 use cases planning

Hi Vladimir, all,

Thanks for all replies received so far!

Vladimir, this is not about meeting time resources, I believe. Meeting time can 
be extended, if necessary.
The limitation and the need to reduce the scope comes from the fact that 
different projects will have to support related functionality, Integration team 
will have to do all integration work around approved use cases etc.

R1 major goal, as Mazin mentioned yesterday, is about merging Openecomp and 
Open-O code and we decided that the best way to achieve this goes though 
implementing R1 use cases. However, we compromised on ONAP Platform 
functionalities – some of them appear on the dedicated wiki page already, some 
more will be included by the community members. And, as also appears in my 
presentation yesterday
“- Issue of the technical debt we are acquiring in R1 and how to pay that off
• If we load R2 at 100% capacity with new features this may never get cleaned 
up and ONAP may eventually collapse under its own complexity.”

When we develop a use case it typically consists of 2 different aspects:


1.   New ONAP platform capabilities

2.   New functionality related to specific use case, including connectivity 
support, support of new VNFs etc.

For example, if we were guided to concentrate on ONAP Platform capabilities 
only, we then would support R2 with R1 only use cases by implementing ONAP 
Platform capabilities missing in R1, and by also aligning this with R2 target 
architecture view. As clearly, (2) above requires additional effort. This, I 
guess, goes back to the question asked by Jason on R2 goal – and, also in my 
view, as Jason put it, “R2 would be about strengthening the non-functional 
aspects of the platform (usability, maintainability, scalability, reliability, 
etc.) to provide an unrivaled, hardened platform that can be leveraged in any 
carrier's environment.”

And, yet another example, if we agree to decide on case-by-case basis, as 
proposed by Vladimir and by Rajesh, we need criteria on how we select to 
support use cases/missing Platform capabilities. And Ranny provided a great 
list of initial criteria to be used for this goal, if we decide to go in this 
direction.

We are looking for more inputs on this, as this will eventually determine the 
direction R2 takes.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D31857.3DBD16A0]

From: Vladimir Yanover (vyanover) [mailto:vyano...@cisco.com]
Sent: Friday, August 18, 2017 12:43 PM
To: Jason Hunt >; Alla Goldner 
>
Cc: onap-tsc@lists.onap.org
Subject: RE: [onap-tsc] R2 use cases planning

Jason, Alla and All
Just to understand the topic, what is this resource that should be managed 
here; is it e.g. meeting time?
Speaking of the #1 below, I understand it as that some ONAP platform 
capabilities are missing so that the agreed R1 use cases cannot be supported. 
If this is the case, the gap certainly should be closed, but it’s R1 work item, 
isn’t it? One therefore can expect that there will be R1 related activities 
(“R1 work items”) and R2 related activities (“R2 work items”) with some 
resource partitioning between them.
Speaking of R2 related activities, we certainly need some selection of use 
cases, but I think it should go on case by case basis: importance, complexity 
of new platform capabilities needed (if any), timeline etc.
Thanks
Vladimir

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Jason Hunt
Sent: Thursday, August 

Re: [onap-tsc] More Help For Adding Committers

[DRAGOSH, PAMELA L (PAM)]

Hey Kenny,

This is great thanks.

As a PTL, I personally feel it is important that committers aren’t just doing 
gerrit commits. But also show meritocracy in the following activities:

· actively participate in Weekly meetings

· respond to onap-discuss questions for that project

· actively help develop wiki information and respond to comments on 
wiki’s

· participate in gerrit reviews not just a submitter, but also review 
other submissions

· actively work with the PTL and other committers with planning for 
sprints, milestones, JIRA

All these items are just as important as someone who simply submits code, they 
ensure a healthy working team.

Thanks,

Pam Dragosh


From:  on behalf of Kenny Paul 

Date: Friday, August 18, 2017 at 2:11 AM
To: Ed Warnicke 
Cc: onap-tsc 
Subject: Re: [onap-tsc] More Help For Adding Committers

Hi Ed,
From the template:

Link(s) demonstrating the Contributor's established history of meritocratic 
contributions to the project:
(Typically this would be in the form of a gerrit query)


So assuming that the template is followed then, yes, that information should be 
provided :-)


Best Regards,
-kenny

Kenny Paul,  Technical Program Manager
kp...@linuxfoundation.org
510.766.5945

On Aug 17, 2017, at 6:48 PM, Ed Warnicke 
> wrote:

Could we add the history of meritocratic contribution via a link to a gerrit 
query for the proposed committers contributions to the repos of the project?

Ed

On Thu, Aug 17, 2017 at 6:40 PM, Kenny Paul 
> wrote:
In a further effort to both ease frustration of the PTLs and address general 
scalability concerns, I have created a template for adding new Committers to an 
ONAP project.
This template can be found by going to the Adding/Removing Committers to a 
Project
 page found under the Developer Best 
Practices
 section of the wiki.

The members of the TSC are closely scrutinizing these types of requests. If you 
have a Contributor that has earned the right to be a Committer, and you have 
not already received a direct email from me indicating that your request has 
been submitted to the TSC for approval, I strongly recommend that you make use 
of the template and follow the process it outlines.

Hopefully this should make things run a bit smoother for all.

Please let me know if you have any questions.

Best Regards,
-kenny

Kenny Paul,  Technical Program Manager
kp...@linuxfoundation.org
510.766.5945


___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc


___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] R2 use cases planning

[Alla Goldner]

Hi Vladimir, all,

Thanks for all replies received so far!

Vladimir, this is not about meeting time resources, I believe. Meeting time can 
be extended, if necessary.
The limitation and the need to reduce the scope comes from the fact that 
different projects will have to support related functionality, Integration team 
will have to do all integration work around approved use cases etc.

R1 major goal, as Mazin mentioned yesterday, is about merging Openecomp and 
Open-O code and we decided that the best way to achieve this goes though 
implementing R1 use cases. However, we compromised on ONAP Platform 
functionalities – some of them appear on the dedicated wiki page already, some 
more will be included by the community members. And, as also appears in my 
presentation yesterday
“- Issue of the technical debt we are acquiring in R1 and how to pay that off
• If we load R2 at 100% capacity with new features this may never get cleaned 
up and ONAP may eventually collapse under its own complexity.”

When we develop a use case it typically consists of 2 different aspects:


1.   New ONAP platform capabilities

2.   New functionality related to specific use case, including connectivity 
support, support of new VNFs etc.

For example, if we were guided to concentrate on ONAP Platform capabilities 
only, we then would support R2 with R1 only use cases by implementing ONAP 
Platform capabilities missing in R1, and by also aligning this with R2 target 
architecture view. As clearly, (2) above requires additional effort. This, I 
guess, goes back to the question asked by Jason on R2 goal – and, also in my 
view, as Jason put it, “R2 would be about strengthening the non-functional 
aspects of the platform (usability, maintainability, scalability, reliability, 
etc.) to provide an unrivaled, hardened platform that can be leveraged in any 
carrier's environment.”

And, yet another example, if we agree to decide on case-by-case basis, as 
proposed by Vladimir and by Rajesh, we need criteria on how we select to 
support use cases/missing Platform capabilities. And Ranny provided a great 
list of initial criteria to be used for this goal, if we decide to go in this 
direction.

We are looking for more inputs on this, as this will eventually determine the 
direction R2 takes.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D31829.1B8EB760]

From: Vladimir Yanover (vyanover) [mailto:vyano...@cisco.com]
Sent: Friday, August 18, 2017 12:43 PM
To: Jason Hunt ; Alla Goldner 
Cc: onap-tsc@lists.onap.org
Subject: RE: [onap-tsc] R2 use cases planning

Jason, Alla and All
Just to understand the topic, what is this resource that should be managed 
here; is it e.g. meeting time?
Speaking of the #1 below, I understand it as that some ONAP platform 
capabilities are missing so that the agreed R1 use cases cannot be supported. 
If this is the case, the gap certainly should be closed, but it’s R1 work item, 
isn’t it? One therefore can expect that there will be R1 related activities 
(“R1 work items”) and R2 related activities (“R2 work items”) with some 
resource partitioning between them.
Speaking of R2 related activities, we certainly need some selection of use 
cases, but I think it should go on case by case basis: importance, complexity 
of new platform capabilities needed (if any), timeline etc.
Thanks
Vladimir

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Jason Hunt
Sent: Thursday, August 17, 2017 10:16 PM
To: Alla Goldner >
Cc: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] R2 use cases planning

Alla,

Thank you for your leadership here and for the work of the use case committee 
on this topic.

ONAP should be able to run any VNF or network service, even ones that aren't 
known today.  And, just as importantly, ONAP needs to manage those VNFs and 
network services well, in a number of various carrier environments.  As you've 
outlined, the question is how we balance those two items.

I agree with all of your points below  -- that R2 should be focused on 
improving the ONAP platform capabilities & only supporting new use cases where 
they are built on existing ONAP functionality.

If the community agrees with this approach, I think we want to be cautious 
about how we present the release's goal externally.  This may require some help 
from the marketing committee, so that R2 isn't viewed as simply reducing 
technical debt.  In my view, R2 would be about strengthening the non-functional 
aspects of the platform (usability, maintainability, scalability, reliability, 
etc.) to provide an unrivaled, hardened platform that can be leveraged in any 
carrier's environment.


Regards,
Jason Hunt
Executive Software Architect, IBM

Phone: 314-749-7422
Email: 

Re: [onap-tsc] R2 use cases planning

[Vladimir Yanover (vyanover)]

Jason, Alla and All
Just to understand the topic, what is this resource that should be managed 
here; is it e.g. meeting time?
Speaking of the #1 below, I understand it as that some ONAP platform 
capabilities are missing so that the agreed R1 use cases cannot be supported. 
If this is the case, the gap certainly should be closed, but it’s R1 work item, 
isn’t it? One therefore can expect that there will be R1 related activities 
(“R1 work items”) and R2 related activities (“R2 work items”) with some 
resource partitioning between them.
Speaking of R2 related activities, we certainly need some selection of use 
cases, but I think it should go on case by case basis: importance, complexity 
of new platform capabilities needed (if any), timeline etc.
Thanks
Vladimir

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Jason Hunt
Sent: Thursday, August 17, 2017 10:16 PM
To: Alla Goldner 
Cc: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] R2 use cases planning

Alla,

Thank you for your leadership here and for the work of the use case committee 
on this topic.

ONAP should be able to run any VNF or network service, even ones that aren't 
known today.  And, just as importantly, ONAP needs to manage those VNFs and 
network services well, in a number of various carrier environments.  As you've 
outlined, the question is how we balance those two items.

I agree with all of your points below  -- that R2 should be focused on 
improving the ONAP platform capabilities & only supporting new use cases where 
they are built on existing ONAP functionality.

If the community agrees with this approach, I think we want to be cautious 
about how we present the release's goal externally.  This may require some help 
from the marketing committee, so that R2 isn't viewed as simply reducing 
technical debt.  In my view, R2 would be about strengthening the non-functional 
aspects of the platform (usability, maintainability, scalability, reliability, 
etc.) to provide an unrivaled, hardened platform that can be leveraged in any 
carrier's environment.


Regards,
Jason Hunt
Executive Software Architect, IBM

Phone: 314-749-7422
Email: djh...@us.ibm.com
Twitter: @DJHunt




From:Alla Goldner 
>
To:"onap-tsc@lists.onap.org" 
>
Date:08/17/2017 01:48 PM
Subject:[onap-tsc] R2 use cases planning
Sent by:
onap-tsc-boun...@lists.onap.org




Hi again,

And in order to start the actual discussion… ☺

My own view is:

1.   We should concentrate on missing ONAP Platform capabilities
2.   New functional use cases can only be considered if
a.   They have big level of similarity/harmonization with R1 use case
b.  They are about extending ONAP Platform capabilities (no introduction of 
new functionality, new PNFs/VNFs, etc.)
3.   We should follow the high level milestones plan presented on the last 
slide



Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D31818.B4D38880]

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Alla Goldner
Sent: Thursday, August 17, 2017 9:39 PM
To: onap-tsc@lists.onap.org
Subject: [onap-tsc] R2 use cases planning

Hi, TSC,

I forward the material I’ve presented today on Usecase subcommittee discussions 
and ask for your feedback.

We need to get guidelines on what to concentrate on for R2.



Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D31818.B4D38880]

From: 
onap-discuss-boun...@lists.onap.org[mailto:onap-discuss-boun...@lists.onap.org]
 On Behalf Of Alla Goldner
Sent: Thursday, August 10, 2017 8:21 PM
To: onap-tsc@lists.onap.org; 
'onap-disc...@lists.onap.org' 
>
Cc: onap-usecase...@lists.onap.org
Subject: [onap-discuss] R2 use cases planning

Hi all,

Unfortunately, we didn’t have time during the TSC meeting to cover R2 use cases 
topic.

I would like to ask you to review the attached presentation, covering status of 
Usecase subcommittee discussions and asking TSC for guidelines on directions we 
should take going forward (Extending ONAP Platform capabilities or introducing 
new functional use cases).
Also, some initial proposal for R2 timelines is part of this input material, 
with emphasize given to pre-R2 milestones related to use cases approval.

It is part of the next meeting agenda, 
https://wiki.onap.org/display/DW/2017-08-17+Meeting+Agenda.
It would be great if we 

[onap-tsc] [R2] Prioritization

[eric.debeau]

Hello

Following discussions in use-case & architecture subcommittees and the TSC, I 
think we should not only focus on use-case definition to drive the R2.

The R1 release will not be perfect and there will be a lot of efforts to 
improve it. We should first prioritize the major topics not solved in R1 (eg 
domain name configuration, High Available an fully manageable installation, 
documentation, ...).
We must be cautious and avoid to enter to a features race when there is still 
some fundamental topics to be solved.

Regards

Eric

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] More Help For Adding Committers

[Kenny Paul]

Hi Ed,
From the template:

Link(s) demonstrating the Contributor's established history of meritocratic 
contributions to the project: 
(Typically this would be in the form of a gerrit query)


So assuming that the template is followed then, yes, that information should be 
provided :-)


Best Regards, 
-kenny

Kenny Paul,  Technical Program Manager
kp...@linuxfoundation.org
510.766.5945

> On Aug 17, 2017, at 6:48 PM, Ed Warnicke  wrote:
> 
> Could we add the history of meritocratic contribution via a link to a gerrit 
> query for the proposed committers contributions to the repos of the project?
> 
> Ed
> 
> On Thu, Aug 17, 2017 at 6:40 PM, Kenny Paul  > wrote:
> In a further effort to both ease frustration of the PTLs and address general 
> scalability concerns, I have created a template for adding new Committers to 
> an ONAP project.
> This template can be found by going to the Adding/Removing Committers to a 
> Project  page 
> found under the Developer Best Practices 
> 
>  section of the wiki.
> 
> The members of the TSC are closely scrutinizing these types of requests. If 
> you have a Contributor that has earned the right to be a Committer, and you 
> have not already received a direct email from me indicating that your request 
> has been submitted to the TSC for approval, I strongly recommend that you 
> make use of the template and follow the process it outlines.
> 
> Hopefully this should make things run a bit smoother for all.
> 
> Please let me know if you have any questions.
> 
> Best Regards, 
> -kenny
> 
> Kenny Paul,  Technical Program Manager
> kp...@linuxfoundation.org 
> 510.766.5945 
> 
> ___
> ONAP-TSC mailing list
> ONAP-TSC@lists.onap.org 
> https://lists.onap.org/mailman/listinfo/onap-tsc 
> 
> 
> 

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc