Re: [aerogear-dev] [feedhenry-dev] Separate APB org or just separate repo

Interesting that firebase pull all functionality for a specific SDK into a single repo [1] rather than repo per feature per client tech... This is the approach we currently take, but in terms of organisation have historically had a single SDK team managing the SDKs. With the new team structures, we could have multiple teams contributing to a single tech-centric repo rather than a specific team who owns the SDKs. [1] https://github.com/firebase/firebase-ios-sdk/tree/master/Firebase -- John Frizelle Chief Architect, Red Hat Mobile Consulting Engineer mobile: *+353 87 290 1644 <//+353872901644>* twitter:* @johnfriz* skype: *john_frizelle* mail: *jfrizell(a)redhat.com <jfrizell(a)redhat.com&gt;* On 13 December 2017 at 14:23, David Martin <davmarti(a)redhat.com&gt; wrote: > My vote is for separate repos for everything as its what's typically done > in communities. > It will immediately be more accessible to community contributors as > they'll likely be contributing to a single thing. > > For example: > > * the keycloak org https://github.com/keycloak has different repos for > the node client, js client & java client. > * Similarly, the prometheus org https://github.com/prometheus has > different repos for each client > * Firebase have different repos for each of their SDKs > https://github.com/firebase/ > > A repo solution that involves mixing languages and concepts in a single > repo is for the benefit of us developing across many things, rather than > community focused. > > > On 13 December 2017 at 14:14, John Frizelle <jfrizell(a)redhat.com&gt; wrote: > >> I'm really not sure I like the idea of a separate org for the APBs - I >> just don't see the value. The APBs are an integral part of what we are >> building - why are we looking to hide them away in a separate org. >> >> I'm also not sure of repo per component. My fear is that we will end up >> with about 10 repos per service. As we grow the number of services, this >> will, IMO, get unmanageable. >> >> I think a good middle ground would be 3 x repos per service >> - Service Impl - The actual service code (UPS, Sync, Keycloak, 3Scale) - >> not all of these will like in AeroGear >> - Service Clients - SDKs (iOS, Android, Cordova etc) and IDE >> Integrations (Android Studio, XCode VS Code etc) >> - Service APB >> >> >> -- >> John Frizelle >> Chief Architect, Red Hat Mobile >> Consulting Engineer >> >> mobile: *+353 87 290 1644 <//+353872901644>* >> twitter:* @johnfriz* >> skype: *john_frizelle* >> mail: *jfrizell(a)redhat.com <jfrizell(a)redhat.com&gt;* >> >> >> >> >> On 13 December 2017 at 14:08, Wojciech Trocki <wtrocki(a)redhat.com&gt; >> wrote: >> >>> >>> >>> On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman <supittma(a)redhat.com&gt; >>> wrote: >>> >>>> >>>> >>>> On Wed, Dec 13, 2017 at 8:46 AM, Matthias Wessendorf < >>>> mwessend(a)redhat.com&gt; wrote: >>>> >>>>> >>>>> >>>>> On Wed, Dec 13, 2017 at 2:36 PM, Craig Brookes <cbrookes(a)redhat.com&gt; >>>>> wrote: >>>>> >>>>>> As mentioned by John having a consistent pattern for our services >>>>>> and their various pieces (cli, apb, ui) etc needs to be figured out. >>>>>> >>>>>> The options: >>>>>> >>>>>> *Single Repo: * We kinda ruled this one out as it unlikely it would >>>>>> work well against 3rd part integrations such as 3scale or keycloak. >>>>>> >>>>>> >>>>>> *Repo for each piece: *Lots of overhead and different repos. Off >>>>>> the top of my head it would be: >>>>>> - repo for any cli piece >>>>>> - repo for client sdks (iOS, android, cordova) etc .. >>>>>> - repo for APB >>>>>> >>>>> >>>>> >>>>> I'd think this is cleanest - each artifact has it's own repository >>>>> >>>>> In addition, I think we could also move all the apbs to its own GH >>>>> org. (aerogearplaybookbundles) >>>>> >>>>> >>>> I think this makes the most sense as well. Tooling likes single >>>> repos, and a separate org let's us point user to the direct shiny things >>>> (in aerogear) with out them getting overwhelmed by infrastructure (apb >>>> repo). >>>> >>>> >>> +1 for this. >>> >>> That will be good separation of concerns for services. Separate >>> organization for apb which is deployment specific. >>> Some services may not have cli so we will initially just have service >>> repository in aerogear and apb in separate org. >>> >>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> *Single Repo for clients* >>>>>> - 1 repo for cli, sdks and (maybe UI too?) >>>>>> - 1 repo for APB (not a client but is a deployment mechanism). >>>>>> >>>>>> >>>>>> Any other or better options people can think of? >>>>>> >>>>>> -- >>>>>> Craig Brookes >>>>>> RHMAP >>>>>> @maleck13 Github >>>>>> >>>>>> _______________________________________________ >>>>>> feedhenry-dev mailing list >>>>>> feedhenry-dev(a)redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Project lead AeroGear.org >>>>> >>>>> _______________________________________________ >>>>> feedhenry-dev mailing list >>>>> feedhenry-dev(a)redhat.com >>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev(a)redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >>> >>> -- >>> >>> WOJCIECH TROCKI >>> >>> Red Hat Mobile <https://www.redhat.com/> >>> >>> IM: wtrocki >>> <https://red.ht/sig> >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev(a)redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev(a)redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) >