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 <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 > >
_______________________________________________ ONAP-TSC mailing list ONAP-TSC@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-tsc
