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

Wed Dec 13 09:52:30 EST 2017

On Wed, Dec 13, 2017 at 9:29 AM, John Frizelle <jfrizell at redhat.com> wrote:

> 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.
>
>
That is the way Google does it, all of their code is in a single repository
https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext

The benefit is a single build system and tests so you know if you broke
anything anywhere.

As long as you are on a multi gigabit internal network you can download
your repository quickly.  However for our use cases we can't guarantee that
for our community.  Additionally the tools will have to support a large
source ecosystem.  We have more control over that, but it would be annoying
to have to configure a tool like repo to make a quick text edit.  These are
the biggest downsides to a large repo, but I do see your point especially
when we count up that each service will have at least 5 logical projects
(service impl, apb, android, ios, js SDKs) these numbers add up quick.

Also I know that raincatcher had a lot of simplicity gained from going to a
mono repo.

> [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)
>>
>
>
> _______________________________________________
> feedhenry-dev mailing list
> feedhenry-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20171213/f3cf37bd/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo.png
Type: image/png
Size: 11472 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20171213/f3cf37bd/attachment-0001.png 