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

Wed Dec 13 14:29:46 UTC 2017

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 at redhat.com <jfrizell at redhat.com>*

On 13 December 2017 at 14:23, David Martin <davmarti at redhat.com> 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 at redhat.com> 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 at redhat.com <jfrizell at redhat.com>*
>>
>>
>>
>>
>> On 13 December 2017 at 14:08, Wojciech Trocki <wtrocki at redhat.com> wrote:
>>
>>>
>>>
>>> On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman <supittma at redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Dec 13, 2017 at 8:46 AM, Matthias Wessendorf <
>>>> mwessend at redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Dec 13, 2017 at 2:36 PM, Craig Brookes <cbrookes at redhat.com>
>>>>> 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 at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Project lead AeroGear.org
>>>>>
>>>>> _______________________________________________
>>>>> feedhenry-dev mailing list
>>>>> feedhenry-dev at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> feedhenry-dev mailing list
>>>> feedhenry-dev at 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 at redhat.com
>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>>
>>>
>>
>> _______________________________________________
>> feedhenry-dev mailing list
>> feedhenry-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>
>>
>
>
> --
> David Martin
> Red Hat Mobile
> Twitter: @irldavem
> IRC: @irldavem (feedhenry, mobile-internal)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20171213/0285f372/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo.png
Type: image/png
Size: 11472 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20171213/0285f372/attachment.png>