Separate APB org or just separate repo

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Separate APB org or just separate repo

Craig Brookes
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

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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Separate APB org or just separate repo

Matthias Wessendorf


On Wed, Dec 13, 2017 at 2:36 PM, Craig Brookes <[hidden email]> 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)

 

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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Separate APB org or just separate repo

Craig Brookes
what is the advantage of moving the apbs to their own org?

On Wed, Dec 13, 2017 at 1:46 PM, Matthias Wessendorf <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 2:36 PM, Craig Brookes <[hidden email]> 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)

 

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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org



--
Craig Brookes
RHMAP 
@maleck13 Github

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Separate APB org or just separate repo

supittma
Administrator
In reply to this post by Matthias Wessendorf


On Wed, Dec 13, 2017 at 8:46 AM, Matthias Wessendorf <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 2:36 PM, Craig Brookes <[hidden email]> 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).  



 
 

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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Separate APB org or just separate repo

Wojciech Trocki


On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 8:46 AM, Matthias Wessendorf <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 2:36 PM, Craig Brookes <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WOJCIECH TROCKI

Red Hat Mobile

IM: wtrocki


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Separate APB org or just separate repo

John Frizelle
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: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 13 December 2017 at 14:08, Wojciech Trocki <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 8:46 AM, Matthias Wessendorf <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 2:36 PM, Craig Brookes <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WOJCIECH TROCKI

Red Hat Mobile

IM: wtrocki


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 13 December 2017 at 14:08, Wojciech Trocki <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 8:46 AM, Matthias Wessendorf <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 2:36 PM, Craig Brookes <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WOJCIECH TROCKI

Red Hat Mobile

IM: wtrocki


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Separate APB org or just separate repo

John Frizelle
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.

--
John Frizelle
Chief Architect, Red Hat Mobile
Consulting Engineer

mobile: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 13 December 2017 at 14:23, David Martin <[hidden email]> 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 <[hidden email]> 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: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 13 December 2017 at 14:08, Wojciech Trocki <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 8:46 AM, Matthias Wessendorf <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 2:36 PM, Craig Brookes <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WOJCIECH TROCKI

Red Hat Mobile

IM: wtrocki


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Separate APB org or just separate repo

Phil Brookes

​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.

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.

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…”

Regards,
Phil.


On Wed, Dec 13, 2017 at 2:29 PM, John Frizelle <[hidden email]> 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.

--
John Frizelle
Chief Architect, Red Hat Mobile
Consulting Engineer

mobile: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 13 December 2017 at 14:23, David Martin <[hidden email]> 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 <[hidden email]> 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: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 13 December 2017 at 14:08, Wojciech Trocki <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 8:46 AM, Matthias Wessendorf <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 2:36 PM, Craig Brookes <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WOJCIECH TROCKI

Red Hat Mobile

IM: wtrocki


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Separate APB org or just separate repo

supittma
Administrator
In reply to this post by John Frizelle


On Wed, Dec 13, 2017 at 9:29 AM, John Frizelle <[hidden email]> 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.



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.

 

--
John Frizelle
Chief Architect, Red Hat Mobile
Consulting Engineer

mobile: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 13 December 2017 at 14:23, David Martin <[hidden email]> 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 <[hidden email]> 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: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 13 December 2017 at 14:08, Wojciech Trocki <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 8:46 AM, Matthias Wessendorf <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 2:36 PM, Craig Brookes <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WOJCIECH TROCKI

Red Hat Mobile

IM: wtrocki


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Separate APB org or just separate repo

Matthias Wessendorf
In reply to this post by Phil Brookes


On Wed, Dec 13, 2017 at 3:44 PM, Phil Brookes <[hidden email]> 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 <[hidden email]> 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.

--
John Frizelle
Chief Architect, Red Hat Mobile
Consulting Engineer

mobile: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 13 December 2017 at 14:23, David Martin <[hidden email]> 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 <[hidden email]> 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: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 13 December 2017 at 14:08, Wojciech Trocki <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 8:46 AM, Matthias Wessendorf <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 2:36 PM, Craig Brookes <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WOJCIECH TROCKI

Red Hat Mobile

IM: wtrocki


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Separate APB org or just separate repo

Wei Li
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 <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 3:44 PM, Phil Brookes <[hidden email]> 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 <[hidden email]> 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.

--
John Frizelle
Chief Architect, Red Hat Mobile
Consulting Engineer

mobile: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 13 December 2017 at 14:23, David Martin <[hidden email]> 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 <[hidden email]> 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: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 13 December 2017 at 14:08, Wojciech Trocki <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 8:46 AM, Matthias Wessendorf <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 2:36 PM, Craig Brookes <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WOJCIECH TROCKI

Red Hat Mobile

IM: wtrocki


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Separate APB org or just separate repo

Phil Brookes

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 <[hidden email]> 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 <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 3:44 PM, Phil Brookes <[hidden email]> 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 <[hidden email]> 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.

--
John Frizelle
Chief Architect, Red Hat Mobile
Consulting Engineer

mobile: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 13 December 2017 at 14:23, David Martin <[hidden email]> 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 <[hidden email]> 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: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 13 December 2017 at 14:08, Wojciech Trocki <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 8:46 AM, Matthias Wessendorf <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 2:36 PM, Craig Brookes <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WOJCIECH TROCKI

Red Hat Mobile

IM: wtrocki


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Separate APB org or just separate repo

Matthias Wessendorf
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 3:44 PM, Phil Brookes <[hidden email]> 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 <[hidden email]> 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.

--
John Frizelle
Chief Architect, Red Hat Mobile
Consulting Engineer

mobile: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 13 December 2017 at 14:23, David Martin <[hidden email]> 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 <[hidden email]> 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: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 13 December 2017 at 14:08, Wojciech Trocki <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 8:46 AM, Matthias Wessendorf <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 2:36 PM, Craig Brookes <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WOJCIECH TROCKI

Red Hat Mobile

IM: wtrocki


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    





--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Separate APB org or just separate repo

Wei Li
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? 

I think that's right, but in most cases, wouldn't they create the APB in their own orgs anyway, so they can keep maintaining the APBs? 

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.

I was talking about our own services, like sync/push etc.

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…”

This probably is the best reason I can see so far to have a separated org, but we can achieve the same thing if we just make sure all the APB repo names contains "apb" and developers will be able to quickly find the anyway. So does it really worth the efforts to maintain another org, as of now? Should we just leave them in the same org for now, and we can move them out if the community feels like it's the right thing to do?
 


On Wed, Dec 13, 2017 at 4:49 PM, Matthias Wessendorf <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 3:44 PM, Phil Brookes <[hidden email]> 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 <[hidden email]> 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.

--
John Frizelle
Chief Architect, Red Hat Mobile
Consulting Engineer

mobile: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 13 December 2017 at 14:23, David Martin <[hidden email]> 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 <[hidden email]> 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: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 13 December 2017 at 14:08, Wojciech Trocki <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 8:46 AM, Matthias Wessendorf <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 2:36 PM, Craig Brookes <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WOJCIECH TROCKI

Red Hat Mobile

IM: wtrocki


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    





--
Project lead AeroGear.org



--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

[hidden email]    M: <a href="tel:+353862393272" style="color:rgb(0,136,206);font-size:11px;margin:0px" target="_blank">+353862393272    


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev
Reply | Threaded
Open this post in threaded view
|

Re: Separate APB org or just separate repo

Wojciech Trocki
In reply to this post by John Frizelle
In relation to Firebase:

What's worth to mention that apart from having all source in the single repository all components are published as separate artifacts.
For example in IOS you can use only Storage or auth by executing:

pod 'Firebase/Storage'

They have done the same for js-sdk, by having multiple npm modules in mono repo:


They using proven tool: lerna to manage all npm packages.




On Wed, Dec 13, 2017 at 2:29 PM, John Frizelle <[hidden email]> 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.

--
John Frizelle
Chief Architect, Red Hat Mobile
Consulting Engineer

mobile: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 13 December 2017 at 14:23, David Martin <[hidden email]> 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 <[hidden email]> 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: <a href="tel://+353872901644" target="_blank">+353 87 290 1644
twitter: @johnfriz
skype: john_frizelle




On 13 December 2017 at 14:08, Wojciech Trocki <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 8:46 AM, Matthias Wessendorf <[hidden email]> wrote:


On Wed, Dec 13, 2017 at 2:36 PM, Craig Brookes <[hidden email]> 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
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
Project lead AeroGear.org

_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WOJCIECH TROCKI

Red Hat Mobile

IM: wtrocki


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev



_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)




--

WOJCIECH TROCKI

Red Hat Mobile

IM: wtrocki


_______________________________________________
feedhenry-dev mailing list
[hidden email]
https://www.redhat.com/mailman/listinfo/feedhenry-dev