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

2017-08-04 Thread GILBERT, MAZIN E (MAZIN E) 
Helen

Sounds like a good move. I am still out Monday so I depend on Kenny on this to 
collect feedback from the PTLs.

Please be flexible for R1 as there is expectation of seed code as part of the 
merger.

Thanks

Mazin

Sent through AT&T's fastest network

On Aug 5, 2017, at 2:56 AM, Yunxia Chen 
mailto:helen.c...@huawei.com>> wrote:

Hi, Kenny,

Could you please add a topic for next Monday’s (8/7/2017) “PTL & Coordinators 
Meeting”:

· “ONAP development enforcement for R1 and forward” proposal

I would like to get feedback from PTLs and Coordinators first. And then have 
another three days to get feedback from the community, and hopefully get the 
approval from TSC at 8/10/2017. Then Integration team will work with LF to add 
scripts to enforce what we have agreed.

Regards,

Helen Chen

From: mailto:onap-tsc-boun...@lists.onap.org>> 
on behalf of Gildas Lanilis 
mailto:gildas.lani...@huawei.com>>
Date: Friday, August 4, 2017 at 6:43 AM
To: onap-tsc mailto:onap-tsc@lists.onap.org>>
Subject: Re: [onap-tsc] Enforcing an "Upstream first" approach to ONAP

Hi,

Thanks David for sharing your analysis +1. Big chunk of code should not happen 
(whatever big mean). That is why when TSC reviewed and approved the 
“Development Best 
Practices”
 earlier in July, I had the motto “If there is 1 word to remember "Commit, 
commit, commit" multiple times a day”. During that meeting someone brought the 
issue of submitting code that is not completely done, and the practice of 
submitting “Gerrit Draft 
Features”
 was introduced. This “Gerrit Draft Features” practice provides a way for the 
community to see “code in progress”, to provide early feedback and not commit 
yet in Master (until the feature is really complete).
The unfortunate David’s description of “we’ll build it internally and then 
upstream the code” demonstrates a lack transparency, working in a silo mode, 
that a trustfulness open source community must avoid.

I agree with Oliver and Lushen that the singularity we are currently 
experiencing is about bringing in seed code, onetime event. In case of multiple 
occurrences of such behavior in a single repo, as a community we should  simply 
-2 the code while doing code reviews.

Thanks to Steve, who pointed out the CI guidance we have in place in wiki. At 
the end of the day, in Open Source what matter is working code. And CI 
disciplines
 helps.

Not sure we should spend energy in tooling to control or limit such behavior. I 
think we have bigger fish to catch now. I would be in favor of educating people 
and making them realize everything they do is PUBLIC (thinking about their 
online resume). That should help the community to self-regulate. Also, read the 
lines story I bring each time we meet on the coder who commit code at 5:30 pm 
on a 
Friday
 (fourth bullet))

Some good reading in CI by Jez Humble and David 
Fairley
 (but that requires much more time)

Thanks,
Gildas
ONAP Release Manager
1 415 238 6287

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Stephen Terrill
Sent: Friday, August 04, 2017 3:01 AM
To: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Enforcing an "Upstream first" approach to ONAP

Thanks for sharing your perspective Lusheng, I think its important to get the 
perspectives of the projects into these discussions.  BR, Steve.

From: onap-tsc-boun...@lists.onap.org

Re: [onap-tsc] Logging Enhancements repository creation - OK

2017-08-04 Thread Michael O'Brien 
Team,

Logging repo is now up - we are good to go.
https://git.onap.org/logging-analytics
https://gerrit.onap.org/r/#/admin/projects/logging-analytics


Thank you Gildas and LF helpdesk.



Original Message

From: 
onap-helpd...@rt.linuxfoundation.org

Sent: August 4, 2017 7:57 PM

Subject: [ONAP Helpdesk #43920] Logging Enhancements repository creation



The repo has been created with the permissions set and the invitations sent to 
the committers.

Nexus, Nexus3 and Jenkins are in sync too.



From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Michael O'Brien
Sent: Thursday, August 3, 2017 11:28
To: onap-tsc@lists.onap.org
Subject: [onap-tsc] Logging Enhancements repository creation

ONAP TSC Members,

  Hi, I understand that the Logging Enhancements project has a request for a 
meeting/git/gerrit/sonar/Jenkins config in the queue to the Linux Foudation.

  I see that the team is very busy with parallel requests lately - just 
verifying that the requests are queued. I would like to start going through the 
API - get involved and checkout a POC for R1.

   thank you in advance
  /Michael

https://wiki.onap.org/display/DW/LOG+M1+Release+Planning


Logging Meeting
(Tuesday proposed) - 
https://wiki.onap.org/display/DW/calendar/260b8a93-05dd-476a-ab6c-ce5f14d46a34?calendarName=ONAP%20Meetings%20and%20Events

GIT
https://git.onap.org/logging-analytics

Gerrit
https://gerrit.onap.org/r/#/admin/projects/logging-analytics

Jenkins (TBD)
https://jenkins.onap.org/me/my-views/view/all/

Sonar (TBD)
https://sonar.onap.org/

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

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

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

2017-08-04 Thread MAHER, RANDA 
Dear All,

Excellent comments from Lusheng and Dan.  I concur.
To further expand on Dan’s comments, consider this use case.
Company is using ONAP, but needs specific functionality but can’t wait on ONAP 
release cycle to get it, does the work internally and offers it to ONAP to be 
picked up for next release. Would putting constraints on contribution process 
and creating overhead hinder this type of participation?

Regards,
Randa
ONAP APPC

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of TIMONEY, DAN
Sent: Friday, August 04, 2017 11:52 AM
To: JI, LUSHENG ; onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Enforcing an "Upstream first" approach to ONAP

***Security Advisory: This Message Originated Outside of AT&T ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
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&T 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&T
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: mailto:onap-tsc-boun...@lists.onap.org>> 
on behalf of "JI, LUSHENG" mailto:l...@research.att.com>>
Date: Friday, August 4, 2017 at 1:43 AM
To: "onap-tsc@lists.onap.org" 
mailto:onap-tsc@lists.onap.org>>
Subject: Re: [onap-tsc] Enforcing an "Upstream first" approach to ONAP

***Security Advisory: This Message Originated Outside of AT&T ***
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 d

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

2017-08-04 Thread Yunxia Chen 
Hi, Kenny,

Could you please add a topic for next Monday’s (8/7/2017) “PTL & Coordinators 
Meeting”:

· “ONAP development enforcement for R1 and forward” proposal

I would like to get feedback from PTLs and Coordinators first. And then have 
another three days to get feedback from the community, and hopefully get the 
approval from TSC at 8/10/2017. Then Integration team will work with LF to add 
scripts to enforce what we have agreed.

Regards,

Helen Chen

From:  on behalf of Gildas Lanilis 

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

Hi,

Thanks David for sharing your analysis +1. Big chunk of code should not happen 
(whatever big mean). That is why when TSC reviewed and approved the 
“Development Best 
Practices”
 earlier in July, I had the motto “If there is 1 word to remember "Commit, 
commit, commit" multiple times a day”. During that meeting someone brought the 
issue of submitting code that is not completely done, and the practice of 
submitting “Gerrit Draft 
Features”
 was introduced. This “Gerrit Draft Features” practice provides a way for the 
community to see “code in progress”, to provide early feedback and not commit 
yet in Master (until the feature is really complete).
The unfortunate David’s description of “we’ll build it internally and then 
upstream the code” demonstrates a lack transparency, working in a silo mode, 
that a trustfulness open source community must avoid.

I agree with Oliver and Lushen that the singularity we are currently 
experiencing is about bringing in seed code, onetime event. In case of multiple 
occurrences of such behavior in a single repo, as a community we should  simply 
-2 the code while doing code reviews.

Thanks to Steve, who pointed out the CI guidance we have in place in wiki. At 
the end of the day, in Open Source what matter is working code. And CI 
disciplines helps.

Not sure we should spend energy in tooling to control or limit such behavior. I 
think we have bigger fish to catch now. I would be in favor of educating people 
and making them realize everything they do is PUBLIC (thinking about their 
online resume). That should help the community to self-regulate. Also, read the 
lines story I bring each time we meet on the coder who commit code at 5:30 pm 
on a Friday (fourth 
bullet))

Some good reading in CI by Jez Humble and David 
Fairley
 (but that requires much more time)

Thanks,
Gildas
ONAP Release Manager
1 415 238 6287

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Stephen Terrill
Sent: Friday, August 04, 2017 3:01 AM
To: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Enforcing an "Upstream first" approach to ONAP

Thanks for sharing your perspective Lusheng, I think its important to get the 
perspectives of the projects into these discussions.  BR, Steve.

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of JI, LUSHENG (LUSHENG)
Sent: 04 August 2017 07:43
To: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Enforcing an "Upstream first" approach to ONAP

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

[onap-tsc] Meetings and Bridges

2017-08-04 Thread Kenny Paul 
Community Members!

Over the weekend I will be making some meeting bridge changes to better meet 
the needs of everyone involved in ONAP.  We’ve had a few situations this week 
where teams were unable to start their meetings because another team had 
neglected to end a meeting. In at least one case the meeting was still running 
24 hours later.  That fact combined with several requests for new weekly 
recurring meetings and my better understanding on how the integration between 
Zoom and G-Cal works (or doesn’t work), is driving these changes.  

My goal is to maintain as many of the existing bridge/meeting pairs as I can, 
but some bridge information will absolutely need to change. 
The calendar located on the bottom of the Community Meetings page will always 
have the most up-to-date information.
https://wiki.onap.org/pages/viewpage.action?pageId=6587439 


I will send a notice out when I’m finished making adjustments.

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] ONAP VoLTE SDC call

2017-08-04 Thread SHADMI, DAVID 
Can we use the SDC call on Monday 8am PDT to discuss the WAN service descriptor?

Thanks,
David

From: yuan@zte.com.cn [mailto:yuan@zte.com.cn]
Sent: Thursday, August 03, 2017 10:49 PM
To: SHADMI, DAVID ; huang.zhuo...@zte.com.cn
Cc: denghu...@huawei.com; onap-disc...@lists.onap.org; onap-tsc@lists.onap.org; 
KAPELUTO, ZAHI ; ROZIN, EDEN 
Subject: 答复: Re: [onap-tsc] ONAP VoLTE SDC call


Congratulations! Great progress for ONAP R1.

@David:  SO, SDNC, SDC team and WAN provider of Volte usecase(ZTE and CMCC) 
might have further work on defining of WAN service descriptor which is not as 
clear as NS descriptor.

@Zhuoyao Huang: please prepare and arrange discussion with related teams.

Thank you all!



Yuan Yue





袁越 yuanyue

资深战略规划师   Senior Strategy Planner

技术规划部/技术规划部/系统产品 Technology Planning Dept./Technology Planning Dept./System 
Product


[cid:image001.gif@01D30D1C.CD809DC0]

[cid:image002.gif@01D30D1C.CD809DC0]
南京市雨花区软件大道50号中兴通讯3号楼
1/F,Building 3, ZTE Nanjing R&D Center II, No.50, Software Avenue,YuHua 
District,Nanjing,P.R.China 210012

T: +025 88013478
M: +86 13851446442
E: yuan@zte.com.cn
www.zte.com.cn

原始邮件
发件人： mailto:ds2...@att.com>>;
收件人： mailto:denghu...@huawei.com>>; 
mailto:onap-disc...@lists.onap.org>>; 
mailto:onap-tsc@lists.onap.org>>;
抄送人： mailto:zk0...@intl.att.com>>; 
mailto:er4...@intl.att.com>>;
日 期 ：2017年08月04日 01:52
主 题 ：Re: [onap-tsc] ONAP VoLTE SDC call


All,

SDC can support SO suggestion for VoLTE service design presented in th call.

With that, I believe we concluded the discussion about the different options, 
and we are moving forward with Option A.

1.   SDC supports onboarding the vIMS and vEPC validated (VNF SDK) VNFs.

2.   vIMS, vEPC, and WAN services design in SDC.

3.   VoLTE service design in SDC.

4.   Distribution of the 4 services to SO, SDNC, VF-C, A&AI.

Regards,
David

-Original Appointment-
 From: LANDO, MICHAEL On Behalf Of denghui (L)
 Sent: Thursday, August 03, 2017 5:09 AM
 To: denghui (L); KAPELUTO, ZAHI; SHADMI, DAVID; ROZIN, EDEN; 
onap-disc...@lists.onap.org; onap-tsc; 
Lando,Michael
 Subject: FW: ONAP VoLTE SDC call
 When: Thursday, August 03, 2017 9:00 PM-10:00 PM (UTC+08:00) Beijing, 
Chongqing, Hong Kong, Urumqi.
 Where: 
https://zoom.us/j/137904496

-Original Appointment-
 From: denghui (L) [mailto:denghu...@huawei.com]
 Sent: Thursday, August 03, 2017 9:20 AM
 To: denghui (L); 
onap-disc...@lists.onap.org; onap-tsc; 
Lando,Michael
 Subject: ONAP VoLTE SDC call
 When: Thursday, August 03, 2017 9:00 PM-10:00 PM (UTC+08:00) Beijing, 
Chongqing, Hong Kong, Urumqi.
 Where: 
https://zoom.us/j/137904496

Hello all

This is for discussion ONAP VoLTE SDC call.
ONAP Meeting 5 is inviting you to a scheduled Zoom meeting.
Join from PC, Mac, Linux, iOS or Android: 
https://zoom.us/j/137904496
Or iPhone one-tap (US Toll): +14086380968,137904496# or +16465588656,137904496#
Or Telephone:
 Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll)
 Meeting ID: 137 904 496
 International numbers available: 
https://zoom.us/zoomconference?m=mi-ad1sMLWlXByAKLio5vDnd9JYqUR_a

Thanks a lot

DENG Hui





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

Re: [onap-tsc] Migration to *.onap.org

2017-08-04 Thread SPATSCHECK, OLIVER (OLIVER) 

Also not sure if it is entirely black and white. There might be some projects 
we can move in the R1 timeframe if we allow for one project at a time 
migration. Then the PTL can make that choice based on there workload and 
project complexity.

Oliver

> On Aug 4, 2017, at 2:44 AM  EDT, LEFEVRE, CATHERINE  
> wrote:
> 
> ***Security Advisory: This Message Originated Outside of AT&T ***
> Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
> 
> Good morning Stephen,
>  
> Thank you for your feedback.
>  
> I will definitively finalize the high level plan as requested and will 
> organize a call accordingly in the coming days.
> I will also consider Gildas’ feedback based on the discussions we had with 
> the LF Council.
>  
> Best regards
> Catherine
>  
> From: Stephen Terrill [mailto:stephen.terr...@ericsson.com] 
> Sent: Thursday, August 03, 2017 8:22 PM
> To: Lefevre, Catherine ; onap-tsc@lists.onap.org
> Subject: RE: Migration to *.onap.org
>  
> Hi Catherine,
>  
> I can understand the complexities (and this was confirmed internally for me).
>  
> I think that there are some basic things we need to cover, already mentioned 
> by Gildas, such as removing commented references to what is considered 
> proprietary, or owned,  code etc, even if that is not what you are addressing 
> below.
>  
> What could be good to resolve the discussion is to at a high level, like you 
> have, state down the high level options that we have with the associated 
> risks.  E.g.
> -Initial big bang migration 
> o   Start now: 
> §  Move all projects at once 
> ·Advantage: Clean slate for R1
> ·Risk: several weeks to sort out, release 1 delay unmitigated risk.
> §  Move projects one at a time 
> ·Advantage: 
> o   Controlled migration
> ·Disadvantage 
> o   Implication for each project to reference old and new dependancies
> o   Time to migration (could it be done by R1 Release)
> o   Risk delay to R1 due to stablising after migration
> §  Move projects after xxx (code freeze, …?) 
> ·….
> BR,
>  
> Steve
>  
> From: onap-tsc-boun...@lists.onap.org 
> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Lefevre, Catherine
> Sent: 01 August 2017 14:07
> To: onap-tsc@lists.onap.org
> Subject: [onap-tsc] Migration to *.onap.org
>  
> Dear ONAP TSC,
>  
> I fully understand the request about the seed code to be migrated to 
> *.onap.org.
> Nevertheless I want to bring to your attention that this request will require 
> significant effort (development, testing and infrastructure changes)
>   • Coordinate and update Maven dependencies and links
>   • Update namespaces as required
>   • Change the source code in order to align with *.onap.org for each 
> impacted project
>   • Change the development scripts
>   • Review and update automated test cases
>   • Re-adjust the LF infrastructure accordingly, keeping the 
> org.openecomp version in place until the end of migration
> That way each project can control the pace of migration from org.openecomp -> 
> org.onap : especially for the projects that are already based on the previous 
> naming.  
>   • Review and re-adjust build jobs to be approved by CI-Management 
> project
>   • Create a temporary environment to perform the necessary code changes
>   • Plan the migration in order to avoid any drastic impact on the ONAP 
> community
>   • Recreate new docker images and stabilize the complete ONAP Environment
>   • Etc.
>  
> Based on past experience (moving from *.att.com to *.openecomp.org), this 
> effort can take up to several weeks until the ONAP release is completely 
> stabilized
> If we pursue in this direction then it is a major risk for our Amsterdam 
> release to be completed on time.
> We will need to review the scope of ONAP R1 based on our resource capacity.
>  
> Or we can develop a complete migration plan as part of our ONAP R1 commitments
> And implement this migration in October as part of ONAP R2 preparation.
>  
> Is it something we can discuss during our next TSC meeting?
>  
> Thanks in advance for your consideration.
>  
> Many thanks & regards
> Catherine
>  
> Catherine Lefèvre
> AT&T Network and Shared Services
> D2 Platform & Systems Development
> AVP Software Development & Engineering
> ECOMP/ONAP/RUBY/SPP
>  
>  
> Phone: +32 2 418 49 22
> Mobile: +32 475 77 36 73
> catherine.lefe...@intl.att.com
>  
> TEXTING and DRIVING… It Can Wait
> AT&T
> BUROGEST OFFICE PARK SA
> Avenue des Dessus-de-Lives, 2
> 5101 Loyers (Namur)
> Belgium
>  
>  
> NOTE: This email (or its attachments) contains information belonging to the 
> sender, which may be confidential. proprietary and/or legally privileged. The 
> information is intended only for the use of the individual(s) or entity(ies) 
> named above. If you are not the intended recipient, you are hereby notified 
> that any disclosure, distribution or taking of any action in reliance on the 
> content o

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

2017-08-04 Thread TIMONEY, DAN 
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&T 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&T
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&T ***
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 OpenO, OpenECOMP, or member companies own 
code.  As ONAP grows, more and more code will be developed along with ONAP, and 
I have no doubt we will see fewer and fewer mega submissions.



  1.  With all the above said, I do wish that it would be great if the 36 hour 
review deadline rule can be flexible based on submission size.

Thank you for reading.

Lusheng
ONAP DCAE

From:  on behalf of Stephen Terrill 

Date: Thursday, August 3, 2017 at 1:42 PM
To: "onap-tsc@lists.onap.org" 
Subject: Re: [onap-tsc] Enforcing an "Upstream first" approach to ONAP

Hi,

It great that David highlighted this need, just a few thoughts from my 
perspective:

  *   I read that there is general agreement about go

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

2017-08-04 Thread Gildas Lanilis 
Hi,

Thanks David for sharing your analysis +1. Big chunk of code should not happen 
(whatever big mean). That is why when TSC reviewed and approved the 
“Development Best 
Practices”
 earlier in July, I had the motto “If there is 1 word to remember "Commit, 
commit, commit" multiple times a day”. During that meeting someone brought the 
issue of submitting code that is not completely done, and the practice of 
submitting “Gerrit Draft 
Features”
 was introduced. This “Gerrit Draft Features” practice provides a way for the 
community to see “code in progress”, to provide early feedback and not commit 
yet in Master (until the feature is really complete).
The unfortunate David’s description of “we’ll build it internally and then 
upstream the code” demonstrates a lack transparency, working in a silo mode, 
that a trustfulness open source community must avoid.

I agree with Oliver and Lushen that the singularity we are currently 
experiencing is about bringing in seed code, onetime event. In case of multiple 
occurrences of such behavior in a single repo, as a community we should  simply 
-2 the code while doing code reviews.

Thanks to Steve, who pointed out the CI guidance we have in place in wiki. At 
the end of the day, in Open Source what matter is working code. And CI 
disciplines helps.

Not sure we should spend energy in tooling to control or limit such behavior. I 
think we have bigger fish to catch now. I would be in favor of educating people 
and making them realize everything they do is PUBLIC (thinking about their 
online resume). That should help the community to self-regulate. Also, read the 
lines story I bring each time we meet on the coder who commit code at 5:30 pm 
on a Friday (fourth 
bullet))

Some good reading in CI by Jez Humble and David 
Fairley
 (but that requires much more time)

Thanks,
Gildas
ONAP Release Manager
1 415 238 6287

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Stephen Terrill
Sent: Friday, August 04, 2017 3:01 AM
To: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Enforcing an "Upstream first" approach to ONAP

Thanks for sharing your perspective Lusheng, I think its important to get the 
perspectives of the projects into these discussions.  BR, Steve.

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of JI, LUSHENG (LUSHENG)
Sent: 04 August 2017 07:43
To: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Enforcing an "Upstream first" approach to ONAP

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 che

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

2017-08-04 Thread Stephen Terrill 
Thanks for sharing your perspective Lusheng, I think its important to get the 
perspectives of the projects into these discussions.  BR, Steve.

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of JI, LUSHENG (LUSHENG)
Sent: 04 August 2017 07:43
To: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Enforcing an "Upstream first" approach to ONAP

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 OpenO, OpenECOMP, or member companies own 
code.  As ONAP grows, more and more code will be developed along with ONAP, and 
I have no doubt we will see fewer and fewer mega submissions.



  1.  With all the above said, I do wish that it would be great if the 36 hour 
review deadline rule can be flexible based on submission size.

Thank you for reading.

Lusheng
ONAP DCAE

From: mailto:onap-tsc-boun...@lists.onap.org>> 
on behalf of Stephen Terrill 
mailto:stephen.terr...@ericsson.com>>
Date: Thursday, August 3, 2017 at 1:42 PM
To: "onap-tsc@lists.onap.org" 
mailto:onap-tsc@lists.onap.org>>
Subject: Re: [onap-tsc] Enforcing an "Upstream first" approach to ONAP

Hi,

It great that David highlighted this need, just a few thoughts from my 
perspective:

  *   I read that there is general agreement about going for upstream first.  
Maybe its not about introducing something new actually.   When looking at our 
Wiki, we already have guidance: 
https://wiki.onap.org/display/DW/Continuous+Integration
  *   We know that the projects are going through a formation and migration and 
merging, and I can respect the effort that entails.  Maybe its enough to 
highlight this for now that after the “migration/formation” that this is not a 
great practice.  Accepting this may occur during the formation phase and is not 
a desired habbit, I wonder whether we could simple ask the PTLs when they will 
be ready to move to continues upstream mode of operation?  Leave the projects 
to define when it makes sense to them in their particular situation.
  *   Anything to do with code styling, best practices, etc.  I agree its great 
to have a desired aligned view.  However lets involve the designers and 
projects, enforcing from “external” may not have traction.  My suggesti