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

Matthias Wessendorf mwessend at redhat.com
Wed Dec 13 11:49:12 EST 2017


yeah, as a logical seperation - that this is just glue code to get things
in, via the service broker.
I share the view that an APB is something different than a (mobile) SDK or
a (server) library

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

> what about client SDKs, or services? Should we create orgs for them as
> well? If not, why APBs are treated differently?
>
> I’m working with some assumptions here, so please correct me if I’ve got
> them wrong.
>
> I think the difference here is that we want and expect the developers of
> other products to develop their own APBs, I do not think that we expect
> external developers to create their own client SDKs for use within MCP?
> Though they may well contribute to the existing client SDKs.
>
> As for the services, wouldn’t an external service be something like Redis
> or MySQL? I’m not sure how that fits into this discussion.
>
> APBs are not consumed by us, they are consumed by the ASB and could have
> their own value outside of the MCP environment.
>
> Regards,
> Phil.
>>
> On Wed, Dec 13, 2017 at 4:34 PM, Wei Li <weil at redhat.com> wrote:
>
>> I am in favour of separate repo for each item as well. However, I am not
>> convinced about separate APB org, or why there is only an org for APBs,
>> what about client SDKs, or services? Should we create orgs for them as
>> well? If not, why APBs are treated differently?
>>
>> I think it's ok to have everything in one org, but I think we should have
>> a website that clearly describe how things are organised. I would image we
>> will have a dedicated page for each service, and from there
>> developers/community members can find everything they need about a service.
>>
>>
>>
>> On Wed, Dec 13, 2017 at 2:54 PM, Matthias Wessendorf <mwessend at redhat.com
>> > wrote:
>>
>>>
>>>
>>> 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
>>>
>>> _______________________________________________
>>> feedhenry-dev mailing list
>>> feedhenry-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>>
>>>
>>
>>
>> --
>>
>> WEI LI
>>
>> SENIOR SOFTWARE ENGINEER
>>
>> Red Hat Mobile <https://www.redhat.com/>
>>
>> weil at redhat.com    M: +353862393272
>> <https://red.ht/sig>
>>
>
>


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


More information about the aerogear-dev mailing list