I'd suggest distributing responsibilities at bit more (rather than centralizing in a Release Manager... that job is hard enough ;) ).
Ed On Fri, Apr 21, 2017 at 12:50 PM, Christopher Donley (Chris) < 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:hagbard at 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 > *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> 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> wrote: > > > > 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/ffa6d388/attachment-0001.html>
