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

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)