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&T's fastest network > On Aug 2, 2017, at 7:37 PM, 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=IKSC5mg8GeOiSar1dax3GQ&m=Ox6br4500P9jahGnamXENkht6L9W002IZBJGbiMNvvM&s=zlTN8uxcV4H9FNf4sXe7QqPKxSZ9X8IcQgY0V41sJ4w&e= > _______________________________________________ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
