Thank you Helen. Appreciate the leadership. Mazin Sent through AT&T'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&T'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&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=IKSC5mg8GeOiSar1dax3GQ&m=rSkZu5gsdRT8HwFjzhd2QXyGHqPCRZUGh5Z88VRAiJs&s=o6YwYnIHiT-aLyFYu-yYBdw3IkZxVziwKVEUvMO7h6c&e=
_______________________________________________ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
