Inline... On Fri, Apr 21, 2017 at 9:22 AM, SPATSCHECK, OLIVER (OLIVER) < spatsch at research.att.com> wrote:
> > I guess you could argue that our current code base is not well formed but > if you look at Gerrit right now you see about 60+ repos for the couple of > components we have. > LOL... I try not to argue that somebody elses work is not well formed till I can understand a bit better both their constraints and reasoning ;) But when they do things that don't make immediate sense to me... I *do* get curious and want to understand :) So about the worst you are going to get from me is that seeking to understand and perhaps some "Have you thought of this" questions :) > > Let?s just start with A. A&AI in my mind is one project. The scope of the > project is to provide a current inventory for ONAP. > > It consist of 5 repos. > > - AAI Chef cookbooks > - AAI Chef environment files > - AAI REST based services > - AAI common logging library > - Loads SDC Models into A&AI > > now could we have thrown all of this into one repo? Sure we could have but > I think they are functionally separate enough that they shouldn?t be in the > same repo so they can be managed separately (e.g. versioning, patches, > releases etc?). Also not every ONAP user might use all of them (e.g. > somebody might not want to use chef and add an ansible repo) > > This is true pretty much for every component we have right now as you can > see in gerrit. > > Now I guess you could argue that we should file a sub project proposal for > each of those repos but I am not sure if e.g. creating two repos for Check > cookbooks and Check environment files is really a decision which needs TSC > input. That could perfectly be handled by the project team. After all we > are trusting the project team to write the code so why not trust them with > this? > Honestly, my preferred mode of oversite in general is to provide information that may be relavent and then defer to the guys doing the work. So please take my comments in that spirit ;) When I see repo proliferation a couple of things come to mind for me: 1) Is that really part of one project with one set of committers? Or is that a new subcommunitee with a new set of committers (or likely to be). In my mind, its much easier in a multi-repo environment to miss the "Hey, that's actually different committers involved and should probably be a new project" mark. 2) Repo splits have costs both way. Multiple repos make it harder for folks to check out all the code, but easier to grab just one corner of it. Multiple repos make builds more complex, but faster. e My past experience has been that TSCs are at their best when they ask projects to *consider* questions, express that they have thought about them, but then defer broadly to the guys on the ground (a projects committers). Do you have thoughts for how that might be done in this situation? Ed > So in my mind this will either lead to: > > A.) unnecessary red tape overhead > B.) people combining things into a single repo because they don?t want to > do the red tape. > > (and believe me I know red tape ?.). Probably you get a bit of both. > > > Oliver > > > On Apr 21, 2017, at 12:07 PM EDT, Ed Warnicke <hagbard at gmail.com> > wrote: > > > > Oliver, > > > > For my edification, can you give an example or two of where a well > scoped project would set up multiple repos? > > > > Ed > > > > On Fri, Apr 21, 2017 at 8:47 AM, SPATSCHECK, OLIVER (OLIVER) < > spatsch at research.att.com> wrote: > > I have another question on the charter. I just noticed that a project > (or sub project) and a repo are the same thing. I find this to be sub > optimal. In my mind a project is a well defined scope of work. A repo has > to do with how to optimize my code management. Am I the only one with the > concern that binding the two will force people into sub optimal repo > structures? > > > > Thx > > > > Oliver > > _______________________________________________ > > ONAP-TSC mailing list > > ONAP-TSC at lists.onap.org > > https://lists.onap.org/mailman/listinfo/onap-tsc > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.onap.org/pipermail/onap-tsc/attachments/20170421/c7646cde/attachment.html>
