That sounds reasonable to me. Oliver
On Apr 21, 2017, at 15:50, Christopher Donley (Chris) <Christopher.Donley at huawei.com<mailto:Christopher.Donley at huawei.com>> wrote: That?s essentially the approach we used in OPEN-O, with the Release Manager handling the coordination ? if a project needed a new repo for a sub-project, etc., the team reached out to Gildas. It worked fairly well. We could update the language in section 1 to allow plural repositories. Beyond that, I suggest not over specifying the mechanism in the charter, and instead provide flexibility to the TSC to deal with issues as they arise. Chris From: Ed Warnicke [mailto:hagb...@gmail.com] Sent: Friday, April 21, 2017 12:34 PM To: SPATSCHECK, OLIVER (OLIVER) Cc: Christopher Donley (Chris); Ed Warnicke; SULLIVAN, BRYAN L; onap-tsc at lists.onap.org<mailto:onap-tsc at lists.onap.org> Subject: Re: [onap-tsc] Updated TSC Charter Inline... On Fri, Apr 21, 2017 at 11:01 AM, SPATSCHECK, OLIVER (OLIVER) <spatsch at research.att.com<mailto:spatsch at research.att.com>> wrote: I think one option would be to stick with the project approval as outline but allow multiple repos in one project as decided by the project team. Then we could have a repo coordinator who provides advice to the projects on repos and races issues (like this should really be two projects) to the TSC as they occur which allows the TSC to intervene (e.g. splitting the project). This sounds like a good start :) Though I would prefer the TSC ask hard questions as to whether a project has grown beyond its scope rather than 'intervening' ;) Ed Similarly to your philosophy I believe into trusting the people which do the work and dealing with problems IF they happen rather then trying to design a process which is heavy handed trying to address anticipated issues which might rarely/never occur. Oliver > On Apr 21, 2017, at 1:47 PM EDT, Ed Warnicke <hagbard at > gmail.com<mailto:hagbard at gmail.com>> wrote: > > Inline... > > On Fri, Apr 21, 2017 at 9:22 AM, SPATSCHECK, OLIVER (OLIVER) <spatsch at > research.att.com<mailto: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<mailto: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<mailto: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<mailto:ONAP-TSC at lists.onap.org> > > https://lists.onap.org/mailman/listinfo/onap-tsc<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=9iyuArzgyekj47PZSPfIijI2cSHsUJtAlcTA0X_udNI&m=jiiKIhZwIGDTTwMWCaHLfVejjQ_-UV0ya6z2IGasC7g&s=0O7MQdrNJ3cXQ2HuMJYcfupdOcp5eZ4_sWq4zqSep3s&e=> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.onap.org/pipermail/onap-tsc/attachments/20170424/c3d09cb3/attachment.html>
