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

[David Martin]

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://lists.jboss.org/pipermail/aerogear-dev/attachments/20171213/626faa9b/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/626faa9b/attachment-0001.png