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 <dt5...@att.com> 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<mailto:dtimo...@att.com>

Office : +1 (732) 420-3226

Mobile : +1 (201) 960-1211

200 S Laurel Ave, Rm E2-2A03

Middletown, NJ 08873



From: <onap-tsc-boun...@lists.onap.org> on behalf of "JI, LUSHENG" 
<l...@research.att.com>
Date: Friday, August 4, 2017 at 1:43 AM
To: "onap-tsc@lists.onap.org" <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 n

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

[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's fastest network

On Aug 5, 2017, at 2:56 AM, Yunxia Chen 
<helen.c...@huawei.com<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: <onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org>> 
on behalf of Gildas Lanilis 
<gildas.lani...@huawei.com<mailto:gildas.lani...@huawei.com>>
Date: Friday, August 4, 2017 at 6:43 AM
To: onap-tsc <onap-tsc@lists.onap.org<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<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_download_attachments_3245207_ONAP-2DDevelopmentBestPractices.pdf-3Fapi-3Dv2=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=2dwD7a5k4V9cZl09O7uTpejnZMF8aa01W3yMqrrZC5Y=Avw5LueTGQHoXOasfmj2n0-boBsc2V8CIHRy89IYfdM=Cpq4EwDyBNhWY6C3Say4NIkko1DMP7Rk02dXeYB1Aoo=>”
 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Configuring-2BGerrit-23ConfiguringGerrit-2DSubmittingadraftfeature=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=2dwD7a5k4V9cZl09O7uTpejnZMF8aa01W3yMqrrZC5Y=Avw5LueTGQHoXOasfmj2n0-boBsc2V8CIHRy89IYfdM=1kSSkOsB9ijo_5X1xduOB0eX8i6_nmVH-_Vy6VtPFYs=>”
 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Continuous-2BIntegration=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=2dwD7a5k4V9cZl09O7uTpejnZMF8aa01W3yMqrrZC5Y=Avw5LueTGQHoXOasfmj2n0-boBsc2V8CIHRy89IYfdM=kh-XiF-9B5JpqnI67BLDflAfoOzkysHBRt1TjsA_g-c=>
 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Continuous-2BIntegration=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=2dwD7a5k4V9cZl09O7uTpejnZMF8aa01W3yMqrrZC5Y=Avw5LueTGQHoXOasfmj2n0-boBsc2V8CIHRy89IYfdM=kh-XiF-9B5JpqnI67BLDflAfoOzkysHBRt1TjsA_g-c=>
 (fourth bullet))

Some good reading in CI by Jez Humble and David 
Fairley<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amazon.com_Continuous-2DDelivery-2DDeployment-2DAutomation-2DAddison-2DWesley_dp_0321601912=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=2dwD7a5k4V9cZl09O7uTpejnZMF8aa01W3yMqrrZC5Y=Avw5LueTGQHoXOasfmj2n0-boBsc2V8CIHRy89IYfdM=kNkmF8qpP3SxiUyS3fti_kNHWac8BC2-bN-NXkWBWwc=>
 (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> 
[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<mailto:onap-tsc@lists.onap.org>
Subject: Re: [onap-tsc] Enforcing an "Upstream first" approach to ONAP

Thanks for 

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

[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 <l...@research.att.com>; 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.
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<mailto:dtimo...@att.com>
Office : +1 (732) 420-3226
Mobile : +1 (201) 960-1211
200 S Laurel Ave, Rm E2-2A03
Middletown, NJ 08873

From: <onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org>> 
on behalf of "JI, LUSHENG" <l...@research.att.com<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>" 
<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 ***
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 

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

[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: <onap-tsc-boun...@lists.onap.org> on behalf of Gildas Lanilis 
<gildas.lani...@huawei.com>
Date: Friday, August 4, 2017 at 6:43 AM
To: onap-tsc <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<https://wiki.onap.org/download/attachments/3245207/ONAP-DevelopmentBestPractices.pdf?api=v2>”
 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<https://wiki.onap.org/display/DW/Configuring+Gerrit#ConfiguringGerrit-Submittingadraftfeature>”
 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<https://wiki.onap.org/display/DW/Continuous+Integration> 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<https://wiki.onap.org/display/DW/Continuous+Integration> (fourth 
bullet))

Some good reading in CI by Jez Humble and David 
Fairley<https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912>
 (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> 
[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<mailto: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 

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

[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 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<mailto:dtimo...@att.com>
Office : +1 (732) 420-3226
Mobile : +1 (201) 960-1211
200 S Laurel Ave, Rm E2-2A03
Middletown, NJ 08873

From: <onap-tsc-boun...@lists.onap.org> on behalf of "JI, LUSHENG" 
<l...@research.att.com>
Date: Friday, August 4, 2017 at 1:43 AM
To: "onap-tsc@lists.onap.org" <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 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: <onap-tsc-boun...@lists.onap.org> on behalf of Stephen Terrill 
<stephen.terr...@ericsson.com>
Date: Thursday, August 3, 2017 at 1:42 PM
To: "onap-tsc@lists.onap.org" &l

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

[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<https://wiki.onap.org/download/attachments/3245207/ONAP-DevelopmentBestPractices.pdf?api=v2>”
 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<https://wiki.onap.org/display/DW/Configuring+Gerrit#ConfiguringGerrit-Submittingadraftfeature>”
 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<https://wiki.onap.org/display/DW/Continuous+Integration> 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<https://wiki.onap.org/display/DW/Continuous+Integration> (fourth 
bullet))

Some good reading in CI by Jez Humble and David 
Fairley<https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912>
 (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> 
[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<mailto: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 su

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

[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: <onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org>> 
on behalf of Stephen Terrill 
<stephen.terr...@ericsson.com<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>" 
<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<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Continuous-2BIntegration=DwMFAg=LFYZ-o9_HUMeMTSQicvjIg=qiKb3LQBLje9oy8MjG3MEx1ia4mIocif7RoUY8WQWV8=t5dp25cmMjv6cRum8ZeBjkB0d-1VdJqF7AjC3yZ0_Jw=u7dbYQ5C7s9xVea7VKhL_KkZI46vTT-t-P3s-9V9qoQ=>
  *   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 

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

[Stephen Terrill]

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 suggestion would 
be to involve them and have TSC approval based on PTL approval first.

Best Regards,

Steve.

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of GILBERT, MAZIN E (MAZIN E)
Sent: 03 August 2017 18:33
To: Yunxia Chen <helen.c...@huawei.com>
Cc: eric.deb...@orange.com; onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Enforcing an "Upstream first" approach to ONAP

Thank you Helen. Appreciate the leadership.
Mazin

Sent through AT's fastest network

On Aug 3, 2017, at 7:00 PM, Yunxia Chen 
<helen.c...@huawei.com<mailto:helen.c...@huawei.com>> wrote:
Hi, Mazin,
The Integration team will take this one as an action item: we will define a 
list, (there's other best code practice as well, such as code review etc.).
with an implementation plan since we may not able to do everything in R1, and 
get TSC's approval.

Regards,

Helen Chen

From: <onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org>> 
on behalf of "GILBERT, MAZIN E (MAZIN E)" 
<ma...@research.att.com<mailto:ma...@research.att.com>>
Date: Thursday, August 3, 2017 at 8:31 AM
To: Eric Debeau <eric.deb...@orange.com<mailto:eric.deb...@orange.com>>
Cc: onap-tsc <onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>>
Subject: Re: [onap-tsc] Enforcing an "Upstream first" approach to ONAP

I am ok if the integration team wants to take the task of defining best code 
practices and guidelines on significant code insertion. I agree with Ash that 
code that can not be reviewed should not be committed blindly. But we need to 
form guidelines so we are all following the same practices. Even the concept of 
significant code is not defined.

This is not a trivial effort and I do not want the integration team to be 
distracted from R1, but I am open for suggestions from the TSC. Let's have the 
discussion via email. I would also appreciate links to successful code best 
practices and enforcements adopted by other forums.

Mazin

Sent through AT's fastest network

On Aug 3, 2017, at 11:35 AM, 
"eric.deb...@orange.com<mailto:eric.deb...@orange.com>" 
<eric.deb...@orange.com<mailto:eric.deb...@orange.com>> wrote:
+1 for raising this topic


We should avoid 10k LOC patches because it is very complex to review and is not 
aligned with an open source spirit.

I do not believe that we should create another subcommitte to handle such 
issue. The integration project may be able to detect such behavior and alerts 
the PTL and TSC

I also agree with Dhananjay => We spend too much effort on functional aspects 
for R1. There is still some issues to setup a full ONAP platform on Vanilla 
OpenStack.

Best 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

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

[GILBERT, MAZIN E (MAZIN E)]

Thank you Helen. Appreciate the leadership.
Mazin

Sent through AT's fastest network

On Aug 3, 2017, at 7:00 PM, Yunxia Chen 
<helen.c...@huawei.com<mailto:helen.c...@huawei.com>> wrote:

Hi, Mazin,
The Integration team will take this one as an action item: we will define a 
list, (there’s other best code practice as well, such as code review etc.).
with an implementation plan since we may not able to do everything in R1, and 
get TSC’s approval.

Regards,

Helen Chen

From: <onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org>> 
on behalf of "GILBERT, MAZIN E (MAZIN E)" 
<ma...@research.att.com<mailto:ma...@research.att.com>>
Date: Thursday, August 3, 2017 at 8:31 AM
To: Eric Debeau <eric.deb...@orange.com<mailto:eric.deb...@orange.com>>
Cc: onap-tsc <onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>>
Subject: Re: [onap-tsc] Enforcing an "Upstream first" approach to ONAP

I am ok if the integration team wants to take the task of defining best code 
practices and guidelines on significant code insertion. I agree with Ash that 
code that can not be reviewed should not be committed blindly. But we need to 
form guidelines so we are all following the same practices. Even the concept of 
significant code is not defined.

This is not a trivial effort and I do not want the integration team to be 
distracted from R1, but I am open for suggestions from the TSC. Let's have the 
discussion via email. I would also appreciate links to successful code best 
practices and enforcements adopted by other forums.

Mazin

Sent through AT's fastest network

On Aug 3, 2017, at 11:35 AM, 
"eric.deb...@orange.com<mailto:eric.deb...@orange.com>" 
<eric.deb...@orange.com<mailto:eric.deb...@orange.com>> wrote:
+1 for raising this topic


We should avoid 10k LOC patches because it is very complex to review and is not 
aligned with an open source spirit.

I do not believe that we should create another subcommitte to handle such 
issue. The integration project may be able to detect such behavior and alerts 
the PTL and TSC

I also agree with Dhananjay => We spend too much effort on functional aspects 
for R1. There is still some issues to setup a full ONAP platform on Vanilla 
OpenStack.

Best 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<mailto:ONAP-TSC@lists.onap.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=IKSC5mg8GeOiSar1dax3GQ=rSkZu5gsdRT8HwFjzhd2QXyGHqPCRZUGh5Z88VRAiJs=o6YwYnIHiT-aLyFYu-yYBdw3IkZxVziwKVEUvMO7h6c=
___
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

[Yunxia Chen]

Hi, Mazin,
The Integration team will take this one as an action item: we will define a 
list, (there’s other best code practice as well, such as code review etc.).
with an implementation plan since we may not able to do everything in R1, and 
get TSC’s approval.

Regards,

Helen Chen

From: <onap-tsc-boun...@lists.onap.org> on behalf of "GILBERT, MAZIN E (MAZIN 
E)" <ma...@research.att.com>
Date: Thursday, August 3, 2017 at 8:31 AM
To: Eric Debeau <eric.deb...@orange.com>
Cc: onap-tsc <onap-tsc@lists.onap.org>
Subject: Re: [onap-tsc] Enforcing an "Upstream first" approach to ONAP

I am ok if the integration team wants to take the task of defining best code 
practices and guidelines on significant code insertion. I agree with Ash that 
code that can not be reviewed should not be committed blindly. But we need to 
form guidelines so we are all following the same practices. Even the concept of 
significant code is not defined.

This is not a trivial effort and I do not want the integration team to be 
distracted from R1, but I am open for suggestions from the TSC. Let's have the 
discussion via email. I would also appreciate links to successful code best 
practices and enforcements adopted by other forums.

Mazin

Sent through AT's fastest network

On Aug 3, 2017, at 11:35 AM, 
"eric.deb...@orange.com<mailto:eric.deb...@orange.com>" 
<eric.deb...@orange.com<mailto:eric.deb...@orange.com>> wrote:
+1 for raising this topic


We should avoid 10k LOC patches because it is very complex to review and is not 
aligned with an open source spirit.

I do not believe that we should create another subcommitte to handle such 
issue. The integration project may be able to detect such behavior and alerts 
the PTL and TSC

I also agree with Dhananjay => We spend too much effort on functional aspects 
for R1. There is still some issues to setup a full ONAP platform on Vanilla 
OpenStack.

Best 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<mailto:ONAP-TSC@lists.onap.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=IKSC5mg8GeOiSar1dax3GQ=rSkZu5gsdRT8HwFjzhd2QXyGHqPCRZUGh5Z88VRAiJs=o6YwYnIHiT-aLyFYu-yYBdw3IkZxVziwKVEUvMO7h6c=
___
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

[GILBERT, MAZIN E (MAZIN E)]

I am ok if the integration team wants to take the task of defining best code 
practices and guidelines on significant code insertion. I agree with Ash that 
code that can not be reviewed should not be committed blindly. But we need to 
form guidelines so we are all following the same practices. Even the concept of 
significant code is not defined.

This is not a trivial effort and I do not want the integration team to be 
distracted from R1, but I am open for suggestions from the TSC. Let's have the 
discussion via email. I would also appreciate links to successful code best 
practices and enforcements adopted by other forums.

Mazin

Sent through AT's fastest network

On Aug 3, 2017, at 11:35 AM, 
"eric.deb...@orange.com" 
> wrote:

+1 for raising this topic


We should avoid 10k LOC patches because it is very complex to review and is not 
aligned with an open source spirit.

I do not believe that we should create another subcommitte to handle such 
issue. The integration project may be able to detect such behavior and alerts 
the PTL and TSC

I also agree with Dhananjay => We spend too much effort on functional aspects 
for R1. There is still some issues to setup a full ONAP platform on Vanilla 
OpenStack.

Best 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=IKSC5mg8GeOiSar1dax3GQ=rSkZu5gsdRT8HwFjzhd2QXyGHqPCRZUGh5Z88VRAiJs=o6YwYnIHiT-aLyFYu-yYBdw3IkZxVziwKVEUvMO7h6c=
___
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

[Ed Warnicke]

I do tend to agree with Oliver here.  There is a process of simply getting
existing code upstream at all.  Ideally, this happens with all the 'seed'
code for a project going out at project creation.   Early on in
communities, this is sometimes difficult for a variety of reasons.  As
communities mature they get better at it.

One other thing that I notice going on that always concerns me is the TSC
wanting to impose requirements on code quality and code review.  Doing so
may be within our purview, but based on past experience I would counsel
great caution in doing so.  I have seen TSCs do great harm to their
communities imposing requirements that sounded good, but for a variety of
reasons weren't.  For this reason, I would suggest the following heuristic
on such things:

1)  Measure first - if we think we want to require something, express it a
guideline but not a requirement and measure the rate at which it's
happening over the course of a release.
2)  Seek to Understand - if its not happening over the course of its
measure first release, try to find out why.  It is sometimes the case that
things don't happen and for reasons not always obvious to the TSC, they
shouldn't.
3)  Evaluate - Part of what comes out of 'Measure First' and 'Seek to
Understand' in the case of things we think that should happen aren't
happening is because they turn out to be very very expensive.  At this
point, we need to have a cost benefit analysis.  Examples: Is this
requirement truly worth halving developer productivity? (maybe, maybe
not).  Is this requirement worth increasing mean patch review time from one
day to two weeks (maybe, maybe not).  Is this requirement actually cheap,
but annoys the crap out of devs (this actually happens a lot)?   What are
the benefits of this requirement we are seeking?   Are we sure they will
materialize?

TSC's wield great power in very a very complex non-hierarchical system...
it is wise to wield that power gently and with humility.  Including in
setting these sorts of requirements.

Ed

On Thu, Aug 3, 2017 at 5:49 AM, SPATSCHECK, OLIVER (OLIVER) <
spat...@research.att.com> wrote:

>
> I think we all agree on the goal. I do wonder though how much of what you
> see is an artifact of projects getting established and moving large pre
> existing code fragments as seed code into the correct location and how much
> is really new development which has started for this release and been done
> behind closed doors.
>
> My suspicion is that the majority has to do with project formation and
> acquiring/organizing preexisting seed code right now. If a project wants to
> ingest preexisting seed code it makes little sense to do it in smaller
> junks just to meet some commit size benchmark.
>
> On the other hand if we are still seeing this size of commits in October
> we have a problem.
>
> Oliver
>
>
> On Aug 3, 2017, at 2:23 AM, Alla Goldner <alla.gold...@amdocs.com> wrote:
>
> Hi David, all,
>
> Thanks for raising this issue!
>
> Similar to others, I believe we should handle this by creating (and then
> enforcing) best practices on code quality and code reviews starting from
> Release 2.
>
> Best regards,
>
> *Alla Goldner*
>
> Open Network Division
> Amdocs Technology
>
>
> 
>
> *From:* onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-
> boun...@lists.onap.org <onap-tsc-boun...@lists.onap.org>] *On Behalf Of 
> *Sauvageau,
> David
> *Sent:* Wednesday, August 02, 2017 7:37 PM
> *To:* onap-tsc@lists.onap.org
> *Subject:* [onap-tsc] Enforcing an "Upstream first" approach to ONAP
>
> Hi TSC members,
>
> I would like to bring to our attention one major opportunity for
> improvement in the behaviour currently adopted by some of our community
> members.
>
> I am observing a big number of very large commits (10’s of thousands of
> lines of code in a single commit) which to me is a symptom of us not
> working well as a community yet. In order to be successful, I believe
> communities need to adopt an “Upstream first” approach, meaning that every
> single day, the new code is committed upstream. We need to avoid the “we’ll
> build it internally and then upstream the code” approach. This is the only
> way we’ll get traction as a community rather than allowing individual
> companies to push for internal agendas.
>
> With the current approach, it is very difficult for the community to start
> contributing to ongoing projects, or even to know what’s coming up on the
> projects as code is pushed by major chunks with no visibility on the
> roadmap. If we continue supporting such behaviour this will slow down the
> adoption of ONAP in production environments.
>
> I believe it is our responsibility as the TSC to change that behaviour,
> first by educating different organizations how open 

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

[SPATSCHECK, OLIVER (OLIVER)]

I think we all agree on the goal. I do wonder though how much of what you see 
is an artifact of projects getting established and moving large pre existing 
code fragments as seed code into the correct location and how much is really 
new development which has started for this release and been done behind closed 
doors.

My suspicion is that the majority has to do with project formation and 
acquiring/organizing preexisting seed code right now. If a project wants to 
ingest preexisting seed code it makes little sense to do it in smaller junks 
just to meet some commit size benchmark.

On the other hand if we are still seeing this size of commits in October we 
have a problem.

Oliver


On Aug 3, 2017, at 2:23 AM, Alla Goldner 
<alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>> wrote:

Hi David, all,

Thanks for raising this issue!

Similar to others, I believe we should handle this by creating (and then 
enforcing) best practices on code quality and code reviews starting from 
Release 2.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology




From: onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org> 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Sauvageau, David
Sent: Wednesday, August 02, 2017 7:37 PM
To: onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>
Subject: [onap-tsc] Enforcing an "Upstream first" approach to ONAP

Hi TSC members,

I would like to bring to our attention one major opportunity for improvement in 
the behaviour currently adopted by some of our community members.

I am observing a big number of very large commits (10’s of thousands of lines 
of code in a single commit) which to me is a symptom of us not working well as 
a community yet. In order to be successful, I believe communities need to adopt 
an “Upstream first” approach, meaning that every single day, the new code is 
committed upstream. We need to avoid the “we’ll build it internally and then 
upstream the code” approach. This is the only way we’ll get traction as a 
community rather than allowing individual companies to push for internal 
agendas.

With the current approach, it is very difficult for the community to start 
contributing to ongoing projects, or even to know what’s coming up on the 
projects as code is pushed by major chunks with no visibility on the roadmap. 
If we continue supporting such behaviour this will slow down the adoption of 
ONAP in production environments.

I believe it is our responsibility as the TSC to change that behaviour, first 
by educating different organizations how open source should be handled, but 
probably also by putting technical mechanisms to prevent such a behaviour (e.g. 
Limit commit size; enforce multi-company reviews before merge, allow for 
unfinished code in the repo …, any suggestions welcome).

I do not have a specific solution to propose, but I would ask the TSC to open 
up the dialogue on such behaviour. The Amsterdam release is quickly coming and 
I believe this needs to be addressed asap.

I’d like to discuss the topic tomorrow during TSC.

Comments, anyone?

Thanks,


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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Ddisclaimer=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4=S27l99VDRzQ_iZU9kZeYryRytPjTzB6MiMPhfYlhLoU=pTQxDm3QHwxEAdHKN_GIxidZVXBTA39E40XIYmXxVOM=>
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org<mailto:ONAP-TSC@lists.onap.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=3WBYkehchaQg0p_gO26aU_ahomnFHCk_-us7kcQebm4=S27l99VDRzQ_iZU9kZeYryRytPjTzB6MiMPhfYlhLoU=E2TUNSyrxTh2UC95WY-VS57POZGyekyRes4WloON6V0=

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

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

[eric.debeau]

+1 for raising this topic


We should avoid 10k LOC patches because it is very complex to review and is not 
aligned with an open source spirit.

I do not believe that we should create another subcommitte to handle such 
issue. The integration project may be able to detect such behavior and alerts 
the PTL and TSC

I also agree with Dhananjay => We spend too much effort on functional aspects 
for R1. There is still some issues to setup a full ONAP platform on Vanilla 
OpenStack.

Best 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] Enforcing an "Upstream first" approach to ONAP

[Alla Goldner]

Hi David, all,

Thanks for raising this issue!

Similar to others, I believe we should handle this by creating (and then 
enforcing) best practices on code quality and code reviews starting from 
Release 2.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D30C3A.26ED03A0]

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Sauvageau, David
Sent: Wednesday, August 02, 2017 7:37 PM
To: onap-tsc@lists.onap.org
Subject: [onap-tsc] Enforcing an "Upstream first" approach to ONAP

Hi TSC members,

I would like to bring to our attention one major opportunity for improvement in 
the behaviour currently adopted by some of our community members.

I am observing a big number of very large commits (10’s of thousands of lines 
of code in a single commit) which to me is a symptom of us not working well as 
a community yet. In order to be successful, I believe communities need to adopt 
an “Upstream first” approach, meaning that every single day, the new code is 
committed upstream. We need to avoid the “we’ll build it internally and then 
upstream the code” approach. This is the only way we’ll get traction as a 
community rather than allowing individual companies to push for internal 
agendas.

With the current approach, it is very difficult for the community to start 
contributing to ongoing projects, or even to know what’s coming up on the 
projects as code is pushed by major chunks with no visibility on the roadmap. 
If we continue supporting such behaviour this will slow down the adoption of 
ONAP in production environments.

I believe it is our responsibility as the TSC to change that behaviour, first 
by educating different organizations how open source should be handled, but 
probably also by putting technical mechanisms to prevent such a behaviour (e.g. 
Limit commit size; enforce multi-company reviews before merge, allow for 
unfinished code in the repo …, any suggestions welcome).

I do not have a specific solution to propose, but I would ask the TSC to open 
up the dialogue on such behaviour. The Amsterdam release is quickly coming and 
I believe this needs to be addressed asap.

I’d like to discuss the topic tomorrow during TSC.

Comments, anyone?

Thanks,


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 
<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

[Ash Young]

With all respect, I think this might be better characterized. I don't think
the alternative to the current practices is "upstream first". Likewise, I
don't think it makes any sense to develop something that doesn't yet exist
by first forming a project elsewhere, like on Github, just so we can then
import it into ONAP. I'm not sure how that solves the large commits. I
think what we're running into is really the result of large chunks of code
that exist in some other repository, and then being brought into ONAP. Now,
it could be that this is tied to a product and now being offered up as open
source. I would consider this to be the extreme. The bottom line is the
same, large chunks of code make it really tough to review. So, my
suggestion is that that alone should be a curse to a project. I would think
it's almost self-correcting, depending on how you create the peer review
process. If it cannot be reviewed and approved, it doesn't get merged. In
other open source projects, where we were dealing with such large ingests
of code, I have suggested that things be immediately rejected in favor of a
more organic approach to things-- in other words, review the design and
architecture, then slowly start introducing code to support the features.
It really makes it a lot easier to get many people up to speed vs requiring
folks to drink from a fire hose.

So, in short, I think this is review issue, not an upstream first issue.

Best,

Ash



On Wed, Aug 2, 2017 at 11:37 AM, Sauvageau, David 
wrote:

> Hi TSC members,
>
> I would like to bring to our attention one major opportunity for
> improvement in the behaviour currently adopted by some of our community
> members.
>
> I am observing a big number of very large commits (10’s of thousands of
> lines of code in a single commit) which to me is a symptom of us not
> working well as a community yet. In order to be successful, I believe
> communities need to adopt an “Upstream first” approach, meaning that every
> single day, the new code is committed upstream. We need to avoid the “we’ll
> build it internally and then upstream the code” approach. This is the only
> way we’ll get traction as a community rather than allowing individual
> companies to push for internal agendas.
>
> With the current approach, it is very difficult for the community to start
> contributing to ongoing projects, or even to know what’s coming up on the
> projects as code is pushed by major chunks with no visibility on the
> roadmap. If we continue supporting such behaviour this will slow down the
> adoption of ONAP in production environments.
>
> I believe it is our responsibility as the TSC to change that behaviour,
> first by educating different organizations how open source should be
> handled, but probably also by putting technical mechanisms to prevent such
> a behaviour (e.g. Limit commit size; enforce multi-company reviews before
> merge, allow for unfinished code in the repo …, any suggestions welcome).
>
> I do not have a specific solution to propose, but I would ask the TSC to
> open up the dialogue on such behaviour. The Amsterdam release is quickly
> coming and I believe this needs to be addressed asap.
>
> I’d like to discuss the topic tomorrow during TSC.
>
> Comments, anyone?
>
> Thanks,
>
>
>
> ___
> 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] Enforcing an "Upstream first" approach to ONAP

[Ed Warnicke]

I think getting something like statckalytics going is goodness, but I don't
think it gets to the upstream first issue.

Look at David's original complaint about 10k LOC patches coming in, and it
*hinting* at code being developed behind closed doors and being pushed up
in batch.  2 10k LOC patches produce the same 20k LOC total in stackalytics
that 2000 100 LOC patches produce.  So not a great metric of Upstream
Firstness.

The other thing I'd strongly counsel is no hard and fast 'this patch is to
big' rules.  I've personally authored patches that are *very simple* (like
changing the signature on a method used internally to a project) which
result in *huge* patches by LOC (because they touch many callers of that
function).  LOC doesn't really tell you about Upstream Firstness or not,
its merely a hint (many large patches hint strongly at an absence of
upstream firstness).

Ed

On Wed, Aug 2, 2017 at 12:42 PM, Haiby, Ranny (Nokia - US/San Jose USA) <
ranny.ha...@nokia.com> wrote:

> Suggestion for encouraging proper behavior – Can the LF implement a code
> contribution statistics tool (something like OpenStack stackalytics
> <http://stackalytics.com/>) on the ONAP repos? That way we can easily
> track things like average LOC per commit for each project/repo, find
> anomalies and help fix them?
>
>
>
> Are there any statistical/analytics tools used in other LF projects?
>
>
>
> Ranny.
>
>
>
>
>
> *From:* onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-bounces@
> lists.onap.org] *On Behalf Of *Sauvageau, David
> *Sent:* Wednesday, August 2, 2017 9:37 AM
> *To:* onap-tsc@lists.onap.org
> *Subject:* [onap-tsc] Enforcing an "Upstream first" approach to ONAP
>
>
>
> Hi TSC members,
>
>
>
> I would like to bring to our attention one major opportunity for
> improvement in the behaviour currently adopted by some of our community
> members.
>
>
>
> I am observing a big number of very large commits (10’s of thousands of
> lines of code in a single commit) which to me is a symptom of us not
> working well as a community yet. In order to be successful, I believe
> communities need to adopt an “Upstream first” approach, meaning that every
> single day, the new code is committed upstream. We need to avoid the “we’ll
> build it internally and then upstream the code” approach. This is the only
> way we’ll get traction as a community rather than allowing individual
> companies to push for internal agendas.
>
>
>
> With the current approach, it is very difficult for the community to start
> contributing to ongoing projects, or even to know what’s coming up on the
> projects as code is pushed by major chunks with no visibility on the
> roadmap. If we continue supporting such behaviour this will slow down the
> adoption of ONAP in production environments.
>
>
>
> I believe it is our responsibility as the TSC to change that behaviour,
> first by educating different organizations how open source should be
> handled, but probably also by putting technical mechanisms to prevent such
> a behaviour (e.g. Limit commit size; enforce multi-company reviews before
> merge, allow for unfinished code in the repo …, any suggestions welcome).
>
>
>
> I do not have a specific solution to propose, but I would ask the TSC to
> open up the dialogue on such behaviour. The Amsterdam release is quickly
> coming and I believe this needs to be addressed asap.
>
>
>
> I’d like to discuss the topic tomorrow during TSC.
>
>
>
> Comments, anyone?
>
>
>
> Thanks,
>
>
>
>
>
> ___
> 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] Enforcing an "Upstream first" approach to ONAP

[GILBERT, MAZIN E (MAZIN E)]

David

You are raising a valid point and it relates to my previous note to the TSC 
about monitoring and evaluating code quality. I suggested forming a 
subcommittee to make a recommendation. This is vital for the success of ONAP. 

Our first release includes a merger of open ecomp and open-o components. Hence, 
I expect significant new code to be included. What we need to ensure are the 
following:

1. Significant new code is consistent with our project approvals
2. TSC is monitoring significant code contribution and quality. The LF is 
implementing a statistical tool shortly that will enable us to do formal 
monitoring. Kenny can provide an update in our Thursday call.

In the meantime, I am urging committers to review codes properly before any 
check in. PTLs need to ensure significant code commitments align with project 
approvals for R1. 

We can discuss this also in our f2f meeting in September to install guidelines 
and more detailed monitoring for R2. 

Thanks
Mazin  

Sent through AT's fastest network 

> On Aug 2, 2017, at 7:37 PM, Sauvageau, David  wrote:
> 
> Hi TSC members, 
> 
> I would like to bring to our attention one major opportunity for improvement 
> in the behaviour currently adopted by some of our community members. 
> 
> I am observing a big number of very large commits (10’s of thousands of lines 
> of code in a single commit) which to me is a symptom of us not working well 
> as a community yet. In order to be successful, I believe communities need to 
> adopt an “Upstream first” approach, meaning that every single day, the new 
> code is committed upstream. We need to avoid the “we’ll build it internally 
> and then upstream the code” approach. This is the only way we’ll get traction 
> as a community rather than allowing individual companies to push for internal 
> agendas. 
> 
> With the current approach, it is very difficult for the community to start 
> contributing to ongoing projects, or even to know what’s coming up on the 
> projects as code is pushed by major chunks with no visibility on the roadmap. 
> If we continue supporting such behaviour this will slow down the adoption of 
> ONAP in production environments. 
> 
> I believe it is our responsibility as the TSC to change that behaviour, first 
> by educating different organizations how open source should be handled, but 
> probably also by putting technical mechanisms to prevent such a behaviour 
> (e.g. Limit commit size; enforce multi-company reviews before merge, allow 
> for unfinished code in the repo …, any suggestions welcome). 
> 
> I do not have a specific solution to propose, but I would ask the TSC to open 
> up the dialogue on such behaviour. The Amsterdam release is quickly coming 
> and I believe this needs to be addressed asap. 
> 
> I’d like to discuss the topic tomorrow during TSC. 
> 
> Comments, anyone?
> 
> Thanks,
> 
> 
> ___
> ONAP-TSC mailing list
> ONAP-TSC@lists.onap.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=IKSC5mg8GeOiSar1dax3GQ=Ox6br4500P9jahGnamXENkht6L9W002IZBJGbiMNvvM=zlTN8uxcV4H9FNf4sXe7QqPKxSZ9X8IcQgY0V41sJ4w=
>  
___
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

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

Suggestion for encouraging proper behavior – Can the LF implement a code 
contribution statistics tool (something like OpenStack 
stackalytics<http://stackalytics.com/>) on the ONAP repos? That way we can 
easily track things like average LOC per commit for each project/repo, find 
anomalies and help fix them?

Are there any statistical/analytics tools used in other LF projects?

Ranny.


From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Sauvageau, David
Sent: Wednesday, August 2, 2017 9:37 AM
To: onap-tsc@lists.onap.org
Subject: [onap-tsc] Enforcing an "Upstream first" approach to ONAP

Hi TSC members,

I would like to bring to our attention one major opportunity for improvement in 
the behaviour currently adopted by some of our community members.

I am observing a big number of very large commits (10’s of thousands of lines 
of code in a single commit) which to me is a symptom of us not working well as 
a community yet. In order to be successful, I believe communities need to adopt 
an “Upstream first” approach, meaning that every single day, the new code is 
committed upstream. We need to avoid the “we’ll build it internally and then 
upstream the code” approach. This is the only way we’ll get traction as a 
community rather than allowing individual companies to push for internal 
agendas.

With the current approach, it is very difficult for the community to start 
contributing to ongoing projects, or even to know what’s coming up on the 
projects as code is pushed by major chunks with no visibility on the roadmap. 
If we continue supporting such behaviour this will slow down the adoption of 
ONAP in production environments.

I believe it is our responsibility as the TSC to change that behaviour, first 
by educating different organizations how open source should be handled, but 
probably also by putting technical mechanisms to prevent such a behaviour (e.g. 
Limit commit size; enforce multi-company reviews before merge, allow for 
unfinished code in the repo …, any suggestions welcome).

I do not have a specific solution to propose, but I would ask the TSC to open 
up the dialogue on such behaviour. The Amsterdam release is quickly coming and 
I believe this needs to be addressed asap.

I’d like to discuss the topic tomorrow during TSC.

Comments, anyone?

Thanks,


___
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

[Murat Parlakisik]

+1  Upstream first .
thanks to bring this .

murat

On Wed, Aug 2, 2017 at 10:27 AM, Dhananjay Pavgi <
dp00476...@techmahindra.com> wrote:

> +1 on Upstream first. Some views on ONAP’s adoption in production
> environments:
>
>
>
> 1.   Regular Code Quality Analysis to be done.
>
> 2.   Arrive at #TECHDEBT and have it tracked through Jira backlog
>
> 3.   Every release plan MUST cover as to what % of #TECHDEBT would be
> addressed in that release.
>
> 4.   #TECHDEBT to be tracked for each component and entire platform
> as such (imbibe Scrum of Scrum discipline)
>
>
>
> Afraid that we are too focused on functional aspects at the moment that
> are tracked through Jira user stories and Sprint plans. However, we are
> grossly ignoring #TECHDEBT.
>
>
>
> thanks & regards,
>
> Dhananjay Pavgi
>
> Mobile : +91 98220 22264 <+91%2098220%2022264>
>
> [image: cid:image002.png@01CE7323.F2727500]   [image:
> ONAP_logo_Sig]
>
> www.techmahindra.com Platinum Member. Visit :
> http://www.onap.org
>
>
>
> *From:* onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-bounces@
> lists.onap.org] *On Behalf Of *Ed Warnicke
> *Sent:* Wednesday, August 02, 2017 10:42 PM
> *To:* Sauvageau, David <david.sauvag...@bell.ca>
> *Cc:* onap-tsc@lists.onap.org
> *Subject:* Re: [onap-tsc] Enforcing an "Upstream first" approach to ONAP
>
>
>
> +1 Upstream first is crucial.
>
>
>
> Happy to share sane strategies I've seen work in the past if folks are
> interested.
>
>
>
> Ed
>
>
>
> On Wed, Aug 2, 2017 at 9:37 AM, Sauvageau, David <david.sauvag...@bell.ca>
> wrote:
>
> Hi TSC members,
>
>
>
> I would like to bring to our attention one major opportunity for
> improvement in the behaviour currently adopted by some of our community
> members.
>
>
>
> I am observing a big number of very large commits (10’s of thousands of
> lines of code in a single commit) which to me is a symptom of us not
> working well as a community yet. In order to be successful, I believe
> communities need to adopt an “Upstream first” approach, meaning that every
> single day, the new code is committed upstream. We need to avoid the “we’ll
> build it internally and then upstream the code” approach. This is the only
> way we’ll get traction as a community rather than allowing individual
> companies to push for internal agendas.
>
>
>
> With the current approach, it is very difficult for the community to start
> contributing to ongoing projects, or even to know what’s coming up on the
> projects as code is pushed by major chunks with no visibility on the
> roadmap. If we continue supporting such behaviour this will slow down the
> adoption of ONAP in production environments.
>
>
>
> I believe it is our responsibility as the TSC to change that behaviour,
> first by educating different organizations how open source should be
> handled, but probably also by putting technical mechanisms to prevent such
> a behaviour (e.g. Limit commit size; enforce multi-company reviews before
> merge, allow for unfinished code in the repo …, any suggestions welcome).
>
>
>
> I do not have a specific solution to propose, but I would ask the TSC to
> open up the dialogue on such behaviour. The Amsterdam release is quickly
> coming and I believe this needs to be addressed asap.
>
>
>
> I’d like to discuss the topic tomorrow during TSC.
>
>
>
> Comments, anyone?
>
>
>
> Thanks,
>
>
>
>
>
>
> ___
> ONAP-TSC mailing list
> ONAP-TSC@lists.onap.org
> https://lists.onap.org/mailman/listinfo/onap-tsc
>
>
>
> 
> 
>
> Disclaimer:  This message and the information contained herein is
> proprietary and confidential and subject to the Tech Mahindra policy
> statement, you may review the policy at http://www.techmahindra.com/
> Disclaimer.html externally http://tim.techmahindra.com/tim/disclaimer.html
> internally within TechMahindra.
>
> 
> 
>
> ___
> 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] Enforcing an "Upstream first" approach to ONAP

[Dhananjay Pavgi]

+1 on Upstream first. Some views on ONAP’s adoption in production environments:


1.   Regular Code Quality Analysis to be done.

2.   Arrive at #TECHDEBT and have it tracked through Jira backlog

3.   Every release plan MUST cover as to what % of #TECHDEBT would be 
addressed in that release.

4.   #TECHDEBT to be tracked for each component and entire platform as such 
(imbibe Scrum of Scrum discipline)

Afraid that we are too focused on functional aspects at the moment that are 
tracked through Jira user stories and Sprint plans. However, we are grossly 
ignoring #TECHDEBT.

thanks & regards,
Dhananjay Pavgi
Mobile : +91 98220 22264
[cid:image002.png@01CE7323.F2727500]   [ONAP_logo_Sig]
www.techmahindra.com<http://www.techmahindra.com/> Platinum 
Member. Visit : http://www.onap.org<http://www.onap.org/>

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Ed Warnicke
Sent: Wednesday, August 02, 2017 10:42 PM
To: Sauvageau, David <david.sauvag...@bell.ca>
Cc: onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] Enforcing an "Upstream first" approach to ONAP

+1 Upstream first is crucial.

Happy to share sane strategies I've seen work in the past if folks are 
interested.

Ed

On Wed, Aug 2, 2017 at 9:37 AM, Sauvageau, David 
<david.sauvag...@bell.ca<mailto:david.sauvag...@bell.ca>> wrote:
Hi TSC members,

I would like to bring to our attention one major opportunity for improvement in 
the behaviour currently adopted by some of our community members.

I am observing a big number of very large commits (10’s of thousands of lines 
of code in a single commit) which to me is a symptom of us not working well as 
a community yet. In order to be successful, I believe communities need to adopt 
an “Upstream first” approach, meaning that every single day, the new code is 
committed upstream. We need to avoid the “we’ll build it internally and then 
upstream the code” approach. This is the only way we’ll get traction as a 
community rather than allowing individual companies to push for internal 
agendas.

With the current approach, it is very difficult for the community to start 
contributing to ongoing projects, or even to know what’s coming up on the 
projects as code is pushed by major chunks with no visibility on the roadmap. 
If we continue supporting such behaviour this will slow down the adoption of 
ONAP in production environments.

I believe it is our responsibility as the TSC to change that behaviour, first 
by educating different organizations how open source should be handled, but 
probably also by putting technical mechanisms to prevent such a behaviour (e.g. 
Limit commit size; enforce multi-company reviews before merge, allow for 
unfinished code in the repo …, any suggestions welcome).

I do not have a specific solution to propose, but I would ask the TSC to open 
up the dialogue on such behaviour. The Amsterdam release is quickly coming and 
I believe this needs to be addressed asap.

I’d like to discuss the topic tomorrow during TSC.

Comments, anyone?

Thanks,



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



Disclaimer:  This message and the information contained herein is proprietary 
and confidential and subject to the Tech Mahindra policy statement, you may 
review the policy at http://www.techmahindra.com/Disclaimer.html 
<http://www.techmahindra.com/Disclaimer.html> externally 
http://tim.techmahindra.com/tim/disclaimer.html 
<http://tim.techmahindra.com/tim/disclaimer.html> internally within 
TechMahindra.


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

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

[Sauvageau, David]

Hi TSC members,

I would like to bring to our attention one major opportunity for improvement in 
the behaviour currently adopted by some of our community members.

I am observing a big number of very large commits (10’s of thousands of lines 
of code in a single commit) which to me is a symptom of us not working well as 
a community yet. In order to be successful, I believe communities need to adopt 
an “Upstream first” approach, meaning that every single day, the new code is 
committed upstream. We need to avoid the “we’ll build it internally and then 
upstream the code” approach. This is the only way we’ll get traction as a 
community rather than allowing individual companies to push for internal 
agendas.

With the current approach, it is very difficult for the community to start 
contributing to ongoing projects, or even to know what’s coming up on the 
projects as code is pushed by major chunks with no visibility on the roadmap. 
If we continue supporting such behaviour this will slow down the adoption of 
ONAP in production environments.

I believe it is our responsibility as the TSC to change that behaviour, first 
by educating different organizations how open source should be handled, but 
probably also by putting technical mechanisms to prevent such a behaviour (e.g. 
Limit commit size; enforce multi-company reviews before merge, allow for 
unfinished code in the repo …, any suggestions welcome).

I do not have a specific solution to propose, but I would ask the TSC to open 
up the dialogue on such behaviour. The Amsterdam release is quickly coming and 
I believe this needs to be addressed asap.

I’d like to discuss the topic tomorrow during TSC.

Comments, anyone?

Thanks,


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