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

Wed Dec 13 09:54:23 EST 2017

On Wed, Dec 13, 2017 at 3:44 PM, Phil Brookes <pbrookes at redhat.com> wrote:

> Hey Everyone,
> 
> I agree with Dave that a separate repo for each item is more community
> friendly. I feel that this will encourage developers to contribute to our
> projects. Primarily because they would only have to learn the scope of the
> part they actually want to contribute to, rather than having to dig through
> a repository which is several projects merged together and work out what is
> and isn’t related to the component that they wish to contribute to.
>
+1
right - it's much simpler to have one repo for "android/java-sync-client"
instead of all "sync-clients" - that way I'd have to deal with the mess I
am not even remotely interested in (e.g. swift-sync-client)

> It is that same mentality that makes me favour a separate org dedicated to
> APBs, as I feel that we would ultimately hope that the developers of other
> products will build and maintain their own APBs, and having a whole
> organisation full of only working examples of how we have achieved their
> goals is a great resource to point those developers at.
>
+1
, for APBs - which are really useless outside of the "service broker" I
think a dedicated ORG has the benefit of drawing logical lines

> i.e. “everything in this org is an APB which might help” vs “well… this
> repo, and this repo and this repo might help but ignore this repo, this
> repo and this repo, they are completely unrelated…”
>

amen :)

> Regards,
> Phil.
> 
>
> On Wed, Dec 13, 2017 at 2:29 PM, 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.
>>
>> [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
>>
>>
>
> _______________________________________________
> feedhenry-dev mailing list
> feedhenry-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>
>

-- 
Project lead AeroGear.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20171213/48eebfbc/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/48eebfbc/attachment-0001.png 