Would it be fair to say this then?: The tsc approach described in the charter applies to projects The tsc approach described in the charter DOES NOT apply to subprojects
Thanks, Daniel Rose ECOMP / ONAP com.att.ecomp 732-420-7308 -----Original Message----- From: onap-tsc-bounces at lists.onap.org [mailto:[email protected]] On Behalf Of SPATSCHECK, OLIVER Sent: Friday, April 21, 2017 12:22 PM To: Ed Warnicke <hagbard at gmail.com> Cc: SULLIVAN, BRYAN L <bs3131 at att.com>; Ed Warnicke <eaw at cisco.com>; onap-tsc at lists.onap.org Subject: Re: [onap-tsc] Updated TSC Charter *** Security Advisory: This Message Originated Outside of AT&T ***. Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. 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. 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? 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=7fQgrg00vjmsI6lDObOMQ5GuJP5yULjerbc7r7aW87k&s=ZSmUVqKmGf-wX91p0D_iHy-NgTvWR5qV7065BPRObr8&e= > > _______________________________________________ ONAP-TSC mailing list ONAP-TSC at lists.onap.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=2wwdGZ3YcpSivQ2Kio028A&m=7fQgrg00vjmsI6lDObOMQ5GuJP5yULjerbc7r7aW87k&s=ZSmUVqKmGf-wX91p0D_iHy-NgTvWR5qV7065BPRObr8&e=
