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

Wei Li weil at redhat.com
Wed Dec 13 11:34:05 EST 2017 

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

More information about the aerogear-dev mailing list