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
