From pwright at redhat.com Mon Dec 4 11:13:54 2017 From: pwright at redhat.com (Paul Wright) Date: Mon, 4 Dec 2017 11:13:54 +0000 Subject: [feedhenry-dev] Doc vs Code Releases Message-ID: <213ff3f1-0ce5-c38f-e82f-2355bb58f7f8@redhat.com> Hi, How would a user distinguish versions as releases continue, eg in a years time and you're finishing up 2.1, how would I pull 1.1 code and docs? Do you intend to use github "releases" or some other tagging? I see 9 releases on RC core [1], but this isn't mirrored on RC docs. Not that there needs to be a one to one mapping, perhaps any release that gets a Release Note update? Paul [1] https://github.com/feedhenry-raincatcher/raincatcher-core/releases Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Mon Dec 4 11:16:19 2017 From: davmarti at redhat.com (David Martin) Date: Mon, 4 Dec 2017 11:16:19 +0000 Subject: [feedhenry-dev] Doc vs Code Releases In-Reply-To: <213ff3f1-0ce5-c38f-e82f-2355bb58f7f8@redhat.com> References: <213ff3f1-0ce5-c38f-e82f-2355bb58f7f8@redhat.com> Message-ID: Hey Paul, Might be one for the feedhenry-raincatcher list On 4 December 2017 at 11:13, Paul Wright wrote: > Hi, > > How would a user distinguish versions as releases continue, eg in a years > time and you're finishing up 2.1, how would I pull 1.1 code and docs? Do > you intend to use github "releases" or some other tagging? I see 9 releases > on RC core [1], but this isn't mirrored on RC docs. > > Not that there needs to be a one to one mapping, perhaps any release that > gets a Release Note update? > > Paul > > [1] https://github.com/feedhenry-raincatcher/raincatcher-core/releases > > Paul > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwright at redhat.com Mon Dec 4 11:19:15 2017 From: pwright at redhat.com (Paul Wright) Date: Mon, 4 Dec 2017 11:19:15 +0000 Subject: [feedhenry-dev] Doc vs Code Releases In-Reply-To: References: <213ff3f1-0ce5-c38f-e82f-2355bb58f7f8@redhat.com> Message-ID: oops, yes, fat fingered, apols Paul On 12/04/2017 11:16 AM, David Martin wrote: > Hey Paul, > > Might be one for the feedhenry-raincatcher list > > On 4 December 2017 at 11:13, Paul Wright > wrote: > > Hi, > > How would a user distinguish versions as releases continue, eg in > a years time and you're finishing up 2.1, how would I pull 1.1 > code and docs? Do you intend to use github "releases" or some > other tagging? I see 9 releases on RC core [1], but this isn't > mirrored on RC docs. > > Not that there needs to be a one to one mapping, perhaps any > release that gets a Release Note update? > > Paul > > [1] > https://github.com/feedhenry-raincatcher/raincatcher-core/releases > > > Paul > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > > > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From supittma at redhat.com Mon Dec 4 13:14:27 2017 From: supittma at redhat.com (Summers Pittman) Date: Mon, 4 Dec 2017 08:14:27 -0500 Subject: [feedhenry-dev] Github organization personal thoughts In-Reply-To: References: Message-ID: On Wed, Nov 29, 2017 at 6:16 AM, Wojciech Trocki wrote: > Feedhenry organization has ~200 repositories at the moment from different > projects, templates and samples with MCP projects along with them. IMHO it > will be easier to promote, organize and collaborate on the organization > that will have only MCP related repositories like service templates. > I might be missing a lots of details so feel free to kill this idea. > > In some of the cases we cannot avoid linking do other organizations (like > digger), but I think it's nice to clean things up and split some > initiatives in order to not confuse potential developers and users. > > It's essential to separate some initiatives and avoid people to get > confused between old feedhenry projects and MCP. We doing great job by > flagging this at the moment like here: https://github.com/feedhenry/ > fh-sync-server , but separate organization will be even cleaner approach > where we can collect documentation, website and all the resources we need. > > It will be easier to do it now with some limited number of MCP > repositories and developers working on it. > > WDYT? > > I do agree that the feedhenry org could use some TLC. I like have as few organizations as possible with coarsely collected repositories inside of them. For now it is probably a good idea to "pin" important repositories on the organizations and make sure the README's in those repos link to the important projects. This will also give us time to make a task out of updating README's to point to 5.x or 3/4.x projects. >From there we have a retrospective from whoever does that work and make a backlog for a better structure overall. > Regards > -- > > WOJCIECH TROCKI > > Red Hat Mobile > > IM: wtrocki > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Mon Dec 4 13:20:06 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Mon, 4 Dec 2017 13:20:06 +0000 Subject: [feedhenry-dev] Github organization personal thoughts In-Reply-To: References: Message-ID: This topic may be little bit outdated as there is open discussion to use aerogear org (and community). On Mon, Dec 4, 2017 at 1:14 PM, Summers Pittman wrote: > > On Wed, Nov 29, 2017 at 6:16 AM, Wojciech Trocki > wrote: > >> Feedhenry organization has ~200 repositories at the moment from different >> projects, templates and samples with MCP projects along with them. IMHO it >> will be easier to promote, organize and collaborate on the organization >> that will have only MCP related repositories like service templates. >> I might be missing a lots of details so feel free to kill this idea. >> >> In some of the cases we cannot avoid linking do other organizations (like >> digger), but I think it's nice to clean things up and split some >> initiatives in order to not confuse potential developers and users. >> >> It's essential to separate some initiatives and avoid people to get >> confused between old feedhenry projects and MCP. We doing great job by >> flagging this at the moment like here: https://github.com/feedhenry/f >> h-sync-server , but separate organization will be even cleaner approach >> where we can collect documentation, website and all the resources we need. >> >> It will be easier to do it now with some limited number of MCP >> repositories and developers working on it. >> >> WDYT? >> >> > I do agree that the feedhenry org could use some TLC. > > I like have as few organizations as possible with coarsely collected > repositories inside of them. For now it is probably a good idea to "pin" > important repositories on the organizations and make sure the README's in > those repos link to the important projects. This will also give us time to > make a task out of updating README's to point to 5.x or 3/4.x projects. > From there we have a retrospective from whoever does that work and make a > backlog for a better structure overall. > > >> Regards >> -- >> >> WOJCIECH TROCKI >> >> Red Hat Mobile >> >> IM: wtrocki >> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > -- WOJCIECH TROCKI Red Hat Mobile IM: wtrocki -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Thu Dec 7 10:10:49 2017 From: davmarti at redhat.com (David Martin) Date: Thu, 7 Dec 2017 10:10:49 +0000 Subject: [feedhenry-dev] Handy mr commands for updating all apb repos Message-ID: For future handiness, If you've already run 'mr register' in each of the cloned apb repos (e.g https://github.com/feedhenry/unifiedpush-apb), here's some commands to update the same file in each repo, and create a PR. In this case, it was updating the apb tools image name. # Checkout master, update it, then checkout a new branch mr run git checkout master mr run git pull origin master mr run git checkout -b update-apb-tools-image # Replace the image name in the Makefile mr run sed -i 's/ansibleplaybookbundle\/apb/ansibleplaybookbundle\/apb-tools/' Makefile # Add, Commit and push mr run git add Makefile mr run git commit -m "Update the apb image to use apb-tools" mr run git push origin update-apb-tools-image # Create the pull requests mr run hub pull-request -b feedhenry:master -m "Update the apb image to use apb-tools" ..... [1] https://myrepos.branchable.com/ [2[ https://github.com/github/hub -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From phajidec at redhat.com Thu Dec 7 12:38:15 2017 From: phajidec at redhat.com (Paolo Haji) Date: Thu, 7 Dec 2017 10:38:15 -0200 Subject: [feedhenry-dev] Handy mr commands for updating all apb repos In-Reply-To: References: Message-ID: This is great info! It's very similar to the part of the rationale for using lerna in RainCatcher, though the main points are the versioning of published npm packages and the symlinking for local development. I was wondering if there is a way to filter repositories form `mr run`, considering for example you could have registered other, non-apb repos under mr. It seems this is possible through a skip param that receives a bash command and passes the repository's name via $1. Looking at more of the documentation of both myrepos and repo it seems they support the notion of sharing the configuration file, so it might be worth looking into having i.e. a small repository/gist with an .mrconfig for the set of apb repos On Thu, Dec 7, 2017 at 8:10 AM, David Martin wrote: > For future handiness, > > If you've already run 'mr register' in each of the cloned apb repos (e.g > https://github.com/feedhenry/unifiedpush-apb), here's some commands to > update the same file in each repo, and create a PR. > In this case, it was updating the apb tools image name. > > > # Checkout master, update it, then checkout a new branch > mr run git checkout master > mr run git pull origin master > mr run git checkout -b update-apb-tools-image > > # Replace the image name in the Makefile > mr run sed -i 's/ansibleplaybookbundle\/apb/ansibleplaybookbundle\/apb-tools/' > Makefile > > # Add, Commit and push > mr run git add Makefile > mr run git commit -m "Update the apb image to use apb-tools" > mr run git push origin update-apb-tools-image > > # Create the pull requests > mr run hub pull-request -b feedhenry:master -m "Update the apb image to > use apb-tools" > ..... > > > > > [1] https://myrepos.branchable.com/ > [2[ https://github.com/github/hub > -- > 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 > > -- PAOLO HAJI SOFTWARE ENGINEER, RED HAT MOBILE APPLICATION PLATFORM Red Hat Brasil phaji at redhat.com TRIED. TESTED. TRUSTED. -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Thu Dec 7 13:06:33 2017 From: davmarti at redhat.com (David Martin) Date: Thu, 7 Dec 2017 13:06:33 +0000 Subject: [feedhenry-dev] Handy mr commands for updating all apb repos In-Reply-To: References: Message-ID: Another option for different groups of repos is having different config files. Then use the '-c' flag based on what you're working on. -c mrconfig --config mrconfig Use the specified mrconfig file. The default is to use both ~/.mrconfig as well as look for a .mrconfig file in the current directory, or in one of its parent directories. On 7 December 2017 at 12:38, Paolo Haji wrote: > This is great info! > It's very similar to the part of the rationale for using lerna > in RainCatcher, though the main points are the > versioning of published npm packages and the symlinking for local > development. > > I was wondering if there is a way to filter repositories form `mr run`, > considering for example you could have registered other, non-apb repos > under mr. > It seems this is possible through a skip param that receives a bash > command and passes the repository's name via $1. > > Looking at more of the documentation of both myrepos and repo > it seems they support the > notion of sharing the configuration file, so it might be worth looking into > having i.e. a small repository/gist with an .mrconfig for the set of apb > repos > > On Thu, Dec 7, 2017 at 8:10 AM, David Martin wrote: > >> For future handiness, >> >> If you've already run 'mr register' in each of the cloned apb repos (e.g >> https://github.com/feedhenry/unifiedpush-apb), here's some commands to >> update the same file in each repo, and create a PR. >> In this case, it was updating the apb tools image name. >> >> >> # Checkout master, update it, then checkout a new branch >> mr run git checkout master >> mr run git pull origin master >> mr run git checkout -b update-apb-tools-image >> >> # Replace the image name in the Makefile >> mr run sed -i 's/ansibleplaybookbundle\/apb/ >> ansibleplaybookbundle\/apb-tools/' Makefile >> >> # Add, Commit and push >> mr run git add Makefile >> mr run git commit -m "Update the apb image to use apb-tools" >> mr run git push origin update-apb-tools-image >> >> # Create the pull requests >> mr run hub pull-request -b feedhenry:master -m "Update the apb image to >> use apb-tools" >> ..... >> >> >> >> >> [1] https://myrepos.branchable.com/ >> [2[ https://github.com/github/hub >> -- >> 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 >> >> > > > -- > > PAOLO HAJI > > SOFTWARE ENGINEER, RED HAT MOBILE APPLICATION PLATFORM > > Red Hat Brasil > > phaji at redhat.com > > TRIED. TESTED. TRUSTED. > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Fri Dec 8 09:54:41 2017 From: davmarti at redhat.com (David Martin) Date: Fri, 8 Dec 2017 09:54:41 +0000 Subject: [feedhenry-dev] Upstream Community Documentation In-Reply-To: References: <7da1aebd-2cdc-104a-a694-b9720d30647c@redhat.com> <87fu8xf6p4.fsf@w541.grdryn> Message-ID: An update on this wrt all Mobile.next()/5.x comms. Immediate change: The day to day chatter is moving to #aerogear on freenode. The aerogear-dev mailing list will be used instead of feedhenry-dev. Eventual changes: All relevant & new Mobile.next()/5.x repositories will eventually make their way over to the aergear github org https://github.com/aerogear All Mobile.next()/5.x upstream documentation will be added to aerogear.org On 30 November 2017 at 13:21, John Frizelle wrote: > Hi All, > > I am meeting with OSAS (the Open Source and Standards group) on Monday to > discuss our Open Source strategy and plans and where OSAS might be able to > assist. > > In this meeting I would like to be to give them a definitive answer on > where the future of our community lies. > > To that end, I would like to ask y'all to take 30 seconds to answer this > one question poll - https://goo.gl/forms/k5GsxMbeu2AY632P2 > > The poll will remain open for *the next 24 hours.* > > Please take the time to cast your vote in this democratic process :-) > > Cheers, > John. > > > -- > John Frizelle > Chief Architect, Red Hat Mobile > Consulting Engineer > > mobile: *+353 87 290 1644 * > twitter:* @johnfriz* > skype: *john_frizelle* > mail: *jfrizell at redhat.com * > > > > > On 30 November 2017 at 11:36, Wei Li wrote: > >> +1 on Dave's idea to move mobile.next work to the AG community. I would >> also add that: >> >> * Rethink/Rebrand the objective of the AG project. I think it should be >> something that is close to what we have for mobile.next >> * In the meantime, make it clear that the FH community will still be >> maintained, but it will only cover for the existing RHMAP projects. >> >> Hopefully this will avoid future confusing around which community is for >> what purpose. It will also allow us to continue support the AG community >> that (I think) have more community users than FH. >> >> Thanks. >> >> On Thu, Nov 30, 2017 at 9:49 AM, David Martin >> wrote: >> >>> TLDR; Let's do all Mobile.next()/5.x development as the Aerogear >>> community >>> >>> >>> I would see the FeedHenry community being strongly linked to RHMAP (Red >>> Hat Mobile App Platform). There are large parts of that community that are >>> tied into having access to a an RHMAP cluster e.g. SDKs & templates (There >>> are some exceptions, which I'll call out later). The RHMAP MBaaS is >>> available on github, but it is not very useful without an RHMAP Core. The >>> RHMAP Core is only available via a RH subscription. >>> >>> I would NOT see the Aerogear community as being strongly tied to RHMAP. >>> The 2 main Aerogear projects are Unified Push Server & Digger (Build Farm). >>> Both of these are standalone services that have been developed in an open >>> manner from their inception. >>> See Ger's points for more about what the Aerogear community is doing >>> well. >>> >>> Building the Aerogear community as the upstream for mobile in Red Hat >>> would draw a line between what's RHMAP 3.x/4.x and the future (5.x). >>> >>> Steps from here: >>> * move the fh-sync-server project into the Aerogear community as the >>> 'Aerogear Data Sync Service' >>> * move mobile.next()/5.x collateral (that's still relevant after the >>> POC) to the Aerogear community >>> * progress development of mobile.next()/5.x as the Aerogear community >>> * update https://aerogear.org >>> ** update UPS documentation (it reference OpenShift 2! There's been >>> great work done on updating UPS for decoupling keycloak & running on >>> OpenShift 3 via APB) >>> ** add Aerogear Data Sync Service documentation >>> ** add Aerogear Digger/Build Farm documentation >>> ** add Aerogear mobile.next() (name TBD) documentation >>> >>> >>> I'm sure there's things I've missed, and would welcome other peoples >>> thoughts on this idea. >>> >>> On 29 November 2017 at 15:25, Gerard Ryan wrote: >>> >>>> Ali Ok writes: >>>> >>>> > I won't go and do a full assessment of both communities/organizations >>>> but >>>> > if we're doing this, we should definitely move these things from >>>> AeroGear >>>> > to FeedHenry side and make sure they don't break in the future at >>>> least the >>>> > current AeroGear things where things are working nicely: >>>> > * Stable processes (release, JIRA workflow, etc.) >>>> > * Open source first mentality (100% community releases, etc.) >>>> > * Somewhat active non Red Hat community members >>>> >>>> So at least the last point there (and maybe the second point also?) >>>> would in my opinion be reasons to move everything *to* the AeroGear >>>> community, rather than *from* it to the FeedHenry community. >>>> >>>> I don't think it makes a huge difference either way for those of us who >>>> work for Red Hat, since we're involved in / aware of both communities as >>>> they are; but it could be potentially disruptive to the more established >>>> AeroGear open source community. >>>> >>>> Since I'm not really involved in that community, I'd like to hear what >>>> matzew or other long-time members of that community think. Maybe it's no >>>> big deal, but I think it's worth thinking about! >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> >> -- >> >> WEI LI >> >> SENIOR SOFTWARE ENGINEER >> >> Red Hat Mobile >> >> weil at redhat.com M: +353862393272 >> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From pbrookes at redhat.com Mon Dec 11 16:29:57 2017 From: pbrookes at redhat.com (Phil Brookes) Date: Mon, 11 Dec 2017 16:29:57 +0000 Subject: [feedhenry-dev] Demostration video of Openshift SAR, Grafana and Prometheus in OpenShift Message-ID: Hey Everyone, I have put together a video demonstrating the latest developments in metrics for 5.x using Grafana to render the metrics stored in Prometheus. Dave Martin and I have been working on this over the course of the last week. This video also demonstrates the OpenShift Subject Access Review rules that can be used to restrict / allow access to services. Prometheus is also using service discovery in this demo to find the services it can scrape metrics for. https://youtu.be/-37OPXXhrTw Any questions or comments, please let me know. Regards, Phil. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Mon Dec 11 16:47:21 2017 From: davmarti at redhat.com (David Martin) Date: Mon, 11 Dec 2017 16:47:21 +0000 Subject: [feedhenry-dev] Demostration video of Openshift SAR, Grafana and Prometheus in OpenShift In-Reply-To: References: Message-ID: Nice video Phil! For anyone wondering about how the proxy stuff works, we're using this application here https://github.com/openshift/oauth-proxy It can sit in front of anything as a reverse proxy, providing authentication (& authorisation via a Subject Access Review request to openshift). It wasn't shown in this video, but the Prometheus Dashboard can also be accessed via an oauth proxy. Prometheus doesn't provide any auth at all, so the proxy provides a very useful service on a publicly exposed route. One other thing that wasn't shown in this video, but was alluded to (and mentioned in a separate video. See https://www.redhat.com/archives/feedhenry-dev/2017-November/msg00023.html) was the service discovery mechanism prometheus used. The fh-sync-server has a particular annotation, which proemthues looks for. It then starts gathering metrics from the /metrics endpoint in fh-sync-server. WRT Grafana, although 2 default dashboards were included with it (Promtetheus & fh-sync-server), the user is free to add their own dashboards or tweak the existing ones. On 11 December 2017 at 16:29, Phil Brookes wrote: > Hey Everyone, > > I have put together a video demonstrating the latest developments in > metrics for 5.x using Grafana to render the metrics stored in Prometheus. > Dave Martin and I have been working on this over the course of the last > week. > > This video also demonstrates the OpenShift Subject Access Review rules > that can be used to restrict / allow access to services. > > Prometheus is also using service discovery in this demo to find the > services it can scrape metrics for. > > https://youtu.be/-37OPXXhrTw > > Any questions or comments, please let me know. > > Regards, > Phil. > ? > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Mon Dec 11 17:03:34 2017 From: davmarti at redhat.com (David Martin) Date: Mon, 11 Dec 2017 17:03:34 +0000 Subject: [feedhenry-dev] Demostration video of Openshift SAR, Grafana and Prometheus in OpenShift In-Reply-To: References: Message-ID: re-replying with aerogear-dev jboss mailing list On 11 December 2017 at 16:47, David Martin wrote: > Nice video Phil! > > For anyone wondering about how the proxy stuff works, > we're using this application here https://github.com/openshift/oauth-proxy > It can sit in front of anything as a reverse proxy, providing > authentication (& authorisation via a Subject Access Review request to > openshift). > > It wasn't shown in this video, but the Prometheus Dashboard can also be > accessed via an oauth proxy. > Prometheus doesn't provide any auth at all, so the proxy provides a very > useful service on a publicly exposed route. > > > One other thing that wasn't shown in this video, but was alluded to (and > mentioned in a separate video. See https://www.redhat.com/ > archives/feedhenry-dev/2017-November/msg00023.html) > was the service discovery mechanism prometheus used. > The fh-sync-server has a particular annotation, which proemthues looks > for. It then starts gathering metrics from the /metrics endpoint in > fh-sync-server. > > WRT Grafana, although 2 default dashboards were included with it > (Promtetheus & fh-sync-server), the user is free to add their own > dashboards or tweak the existing ones. > > On 11 December 2017 at 16:29, Phil Brookes wrote: > >> Hey Everyone, >> >> I have put together a video demonstrating the latest developments in >> metrics for 5.x using Grafana to render the metrics stored in Prometheus. >> Dave Martin and I have been working on this over the course of the last >> week. >> >> This video also demonstrates the OpenShift Subject Access Review rules >> that can be used to restrict / allow access to services. >> >> Prometheus is also using service discovery in this demo to find the >> services it can scrape metrics for. >> >> https://youtu.be/-37OPXXhrTw >> >> Any questions or comments, please let me know. >> >> Regards, >> Phil. >> ? >> >> _______________________________________________ >> 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) > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Tue Dec 12 09:00:58 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Tue, 12 Dec 2017 10:00:58 +0100 Subject: [feedhenry-dev] Openshift issues Message-ID: Hi, I had a few issues getting stuff running (ASB / MCP). The thing that helped me to fix the issue, was really nuking the content of the "/var/lib/origin" folder - that was full w/ lot's of stuff -M -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmadigan at redhat.com Tue Dec 12 17:08:41 2017 From: jmadigan at redhat.com (Jason Madigan) Date: Tue, 12 Dec 2017 17:08:41 +0000 Subject: [feedhenry-dev] Anyone else encountering issues with mail delivery on aerogear-dev? Message-ID: -- Jason Madigan Engineering Manager, Red Hat Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Tue Dec 12 17:10:35 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Tue, 12 Dec 2017 18:10:35 +0100 Subject: [feedhenry-dev] Anyone else encountering issues with mail delivery on aerogear-dev? In-Reply-To: References: Message-ID: https://redhat.service-now.com/surl.do?n=PNT0067920 On Tue, Dec 12, 2017 at 6:08 PM, Jason Madigan wrote: > > > -- > Jason Madigan > Engineering Manager, Red Hat Mobile > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Tue Dec 12 17:11:47 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Tue, 12 Dec 2017 18:11:47 +0100 Subject: [feedhenry-dev] Anyone else encountering issues with mail delivery on aerogear-dev? In-Reply-To: References: Message-ID: I am tempted to ask: is google groups the ultimate fix for this ? :-) On Tue, Dec 12, 2017 at 6:10 PM, Matthias Wessendorf wrote: > https://redhat.service-now.com/surl.do?n=PNT0067920 > > On Tue, Dec 12, 2017 at 6:08 PM, Jason Madigan > wrote: > >> >> >> -- >> Jason Madigan >> Engineering Manager, Red Hat Mobile >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > Project lead AeroGear.org > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Tue Dec 12 17:11:57 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Tue, 12 Dec 2017 18:11:57 +0100 Subject: [feedhenry-dev] Anyone else encountering issues with mail delivery on aerogear-dev? In-Reply-To: References: Message-ID: that said - for me it's currently working fine - lol On Tue, Dec 12, 2017 at 6:11 PM, Matthias Wessendorf wrote: > I am tempted to ask: is google groups the ultimate fix for this ? :-) > > On Tue, Dec 12, 2017 at 6:10 PM, Matthias Wessendorf > wrote: > >> https://redhat.service-now.com/surl.do?n=PNT0067920 >> >> On Tue, Dec 12, 2017 at 6:08 PM, Jason Madigan >> wrote: >> >>> >>> >>> -- >>> Jason Madigan >>> Engineering Manager, Red Hat Mobile >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> Project lead AeroGear.org >> > > > > -- > Project lead AeroGear.org > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfitzger at redhat.com Tue Dec 12 17:13:17 2017 From: lfitzger at redhat.com (Laura Fitzgerald) Date: Tue, 12 Dec 2017 17:13:17 +0000 Subject: [feedhenry-dev] Anyone else encountering issues with mail delivery on aerogear-dev? In-Reply-To: References: Message-ID: I opened a ticket for not receiving emails. https://redhat.service-now.com/surl.do?n=PNT0117426 On Tue, Dec 12, 2017 at 5:10 PM, Matthias Wessendorf wrote: > https://redhat.service-now.com/surl.do?n=PNT0067920 > > On Tue, Dec 12, 2017 at 6:08 PM, Jason Madigan > wrote: > >> >> >> -- >> Jason Madigan >> Engineering Manager, Red Hat Mobile >> >> _______________________________________________ >> 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 > > -- LAURA FITZGERALD Red Hat Mobile Communications House, Cork Road Waterford City, Ireland X91NY33 lfitzger at redhat.com IM: lfitzgerald -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Tue Dec 12 17:15:00 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Tue, 12 Dec 2017 18:15:00 +0100 Subject: [feedhenry-dev] Anyone else encountering issues with mail delivery on aerogear-dev? In-Reply-To: References: Message-ID: and.... https://projects.engineering.redhat.com/browse/JBOSSINFRA-461 On Tue, Dec 12, 2017 at 6:13 PM, Laura Fitzgerald wrote: > I opened a ticket for not receiving emails. > https://redhat.service-now.com/surl.do?n=PNT0117426 > > On Tue, Dec 12, 2017 at 5:10 PM, Matthias Wessendorf > wrote: > >> https://redhat.service-now.com/surl.do?n=PNT0067920 >> >> On Tue, Dec 12, 2017 at 6:08 PM, Jason Madigan >> wrote: >> >>> >>> >>> -- >>> Jason Madigan >>> Engineering Manager, Red Hat Mobile >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > > LAURA FITZGERALD > > Red Hat Mobile > > Communications House, Cork Road > > Waterford City, Ireland X91NY33 > > lfitzger at redhat.com IM: lfitzgerald > > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfitzger at redhat.com Tue Dec 12 17:15:39 2017 From: lfitzger at redhat.com (Laura Fitzgerald) Date: Tue, 12 Dec 2017 17:15:39 +0000 Subject: [feedhenry-dev] Anyone else encountering issues with mail delivery on aerogear-dev? In-Reply-To: References: Message-ID: I couldn't access that JIRA. On Tue, Dec 12, 2017 at 5:15 PM, Matthias Wessendorf wrote: > and.... https://projects.engineering.redhat.com/browse/JBOSSINFRA-461 > > > On Tue, Dec 12, 2017 at 6:13 PM, Laura Fitzgerald > wrote: > >> I opened a ticket for not receiving emails. >> https://redhat.service-now.com/surl.do?n=PNT0117426 >> >> On Tue, Dec 12, 2017 at 5:10 PM, Matthias Wessendorf > > wrote: >> >>> https://redhat.service-now.com/surl.do?n=PNT0067920 >>> >>> On Tue, Dec 12, 2017 at 6:08 PM, Jason Madigan >>> wrote: >>> >>>> >>>> >>>> -- >>>> Jason Madigan >>>> Engineering Manager, Red Hat Mobile >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> >> -- >> >> LAURA FITZGERALD >> >> Red Hat Mobile >> >> Communications House, Cork Road >> >> Waterford City, Ireland X91NY33 >> >> lfitzger at redhat.com IM: lfitzgerald >> >> >> > > > -- > Project lead AeroGear.org > -- LAURA FITZGERALD Red Hat Mobile Communications House, Cork Road Waterford City, Ireland X91NY33 lfitzger at redhat.com IM: lfitzgerald -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Tue Dec 12 17:16:09 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Tue, 12 Dec 2017 18:16:09 +0100 Subject: [feedhenry-dev] Anyone else encountering issues with mail delivery on aerogear-dev? In-Reply-To: References: Message-ID: you need your kerberos On Tue, Dec 12, 2017 at 6:15 PM, Laura Fitzgerald wrote: > I couldn't access that JIRA. > > On Tue, Dec 12, 2017 at 5:15 PM, Matthias Wessendorf > wrote: > >> and.... https://projects.engineering.redhat.com/browse/JBOSSINFRA-461 >> >> >> On Tue, Dec 12, 2017 at 6:13 PM, Laura Fitzgerald >> wrote: >> >>> I opened a ticket for not receiving emails. >>> https://redhat.service-now.com/surl.do?n=PNT0117426 >>> >>> On Tue, Dec 12, 2017 at 5:10 PM, Matthias Wessendorf < >>> mwessend at redhat.com> wrote: >>> >>>> https://redhat.service-now.com/surl.do?n=PNT0067920 >>>> >>>> On Tue, Dec 12, 2017 at 6:08 PM, Jason Madigan >>>> wrote: >>>> >>>>> >>>>> >>>>> -- >>>>> Jason Madigan >>>>> Engineering Manager, Red Hat Mobile >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> >>> >>> -- >>> >>> LAURA FITZGERALD >>> >>> Red Hat Mobile >>> >>> Communications House, Cork Road >>> >>> Waterford City, Ireland X91NY33 >>> >>> lfitzger at redhat.com IM: lfitzgerald >>> >>> >>> >> >> >> -- >> Project lead AeroGear.org >> > > > > -- > > LAURA FITZGERALD > > Red Hat Mobile > > Communications House, Cork Road > > Waterford City, Ireland X91NY33 > > lfitzger at redhat.com IM: lfitzgerald > > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Tue Dec 12 18:03:22 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Tue, 12 Dec 2017 18:03:22 +0000 Subject: [feedhenry-dev] Anyone else encountering issues with mail delivery on aerogear-dev? In-Reply-To: References: Message-ID: +1 for google groups. Other rht teams already using that. On 12 Dec 2017 5:12 pm, "Matthias Wessendorf" wrote: I am tempted to ask: is google groups the ultimate fix for this ? :-) On Tue, Dec 12, 2017 at 6:10 PM, Matthias Wessendorf wrote: > https://redhat.service-now.com/surl.do?n=PNT0067920 > > On Tue, Dec 12, 2017 at 6:08 PM, Jason Madigan > wrote: > >> >> >> -- >> Jason Madigan >> Engineering Manager, Red Hat Mobile >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > Project lead AeroGear.org > -- Project lead AeroGear.org _______________________________________________ feedhenry-dev mailing list feedhenry-dev at redhat.com https://www.redhat.com/mailman/listinfo/feedhenry-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From lgriffin at redhat.com Tue Dec 12 19:00:33 2017 From: lgriffin at redhat.com (Leigh Griffin) Date: Tue, 12 Dec 2017 19:00:33 +0000 Subject: [feedhenry-dev] Anyone else encountering issues with mail delivery on aerogear-dev? In-Reply-To: References: Message-ID: Matthias it might be worth logging in as an Admin and checking settings. I have noticed this over the summer with GSoC and I see some requests get flagged for mod approval. We have a spam problem (admins see this not the list) as well so they might get missed in that noise. I like Google Groups actually, nice option. I'm an Admin as well and can try check Thursday due to QBR tomorrow. If you had time that would be great. Leigh On 12 Dec 2017 18:11, "Wojciech Trocki" wrote: > +1 for google groups. > > Other rht teams already using that. > > On 12 Dec 2017 5:12 pm, "Matthias Wessendorf" wrote: > > I am tempted to ask: is google groups the ultimate fix for this ? :-) > > On Tue, Dec 12, 2017 at 6:10 PM, Matthias Wessendorf > wrote: > >> https://redhat.service-now.com/surl.do?n=PNT0067920 >> >> On Tue, Dec 12, 2017 at 6:08 PM, Jason Madigan >> wrote: >> >>> >>> >>> -- >>> Jason Madigan >>> Engineering Manager, Red Hat Mobile >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> Project lead AeroGear.org >> > > > > -- > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbrookes at redhat.com Wed Dec 13 08:55:39 2017 From: cbrookes at redhat.com (Craig Brookes) Date: Wed, 13 Dec 2017 08:55:39 +0000 Subject: [feedhenry-dev] APB service provision using secrets and configmaps and proposals in general Message-ID: Hey guys, *tldr* *- Use a combination of configmaps and secrets to store public (ie client config) vs secret (ie credentials) when provisioning services via an APB* *- Use proposals for these kind of changes (ie where they are larger changes, breaking changes or changes in technical direction that have cross cutting concerns.)* *- As we have many pieces, setup aerogear/proposals repo.* I would like to suggest that we make use of a mixture of configmap and secrets during the provision of a mobile "aware" service. Currently when we provision a service we must also create a secret with a label: mobile:enabled and at least two pieces of information: - uri - name but it often contains more (such as username and password etc) This secret is used by the UI to represent that the service is present in the namespace and to display the credential information that allows the developer to sign into the service. During the PoC this secret was also used to populate the mobile client config. This meant filtering out fields that we did not want the mobile client to have access to. My suggestion is that we move to using an additional configmap labeled "mobile:enabled" that contains the public information that can be exposed to the mobile client as configuration and a secret still labeled "mobile:enabled" to capture other information such as the credentials for logging into the service. This really amounts to a proposal. Which brings me to the second question. Where to keep proposals? I would like us to standardise on have a public record of technical changes. These proposals should capture the following: 1) What 2) Why 3) How As an example here is a proposal that I put together for the ansible service broker: https://github.com/openshift/ansible-service-broker/blob/master/docs/proposals/last-operation-description.md This shows the kind of level of detail that I believe we should be capturing. When is a proposal necessary? In my experience they are often used for larger changes, breaking changes or changes in technical direction that have cross cutting concerns. So in the case of my change outlined above, it is a breaking change that both the CLI and UI need to be aware of along with the developers of service APBs and so it should be a proposal. In the ansible service broker case the proposal is kept in the docs dir of the repo, however for something larger like Kubernetes they have a separate repo https://github.com/kubernetes/community. We could do something similar: aerogear/proposals with directories for each area - core - ui - cli - ide-extenstions - services - apbs - push - sync ... I think this would allow the owner or gatekeeper of the proposal to be clearly identified. Interested in hearing thoughts and opinions -- Craig Brookes RHMAP @maleck13 Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbrookes at redhat.com Wed Dec 13 09:04:39 2017 From: cbrookes at redhat.com (Craig Brookes) Date: Wed, 13 Dec 2017 09:04:39 +0000 Subject: [feedhenry-dev] prometheus demo Message-ID: Nice video was that all setup with no need for additional perms? -- Craig Brookes RHMAP @maleck13 Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrookes at redhat.com Wed Dec 13 09:31:24 2017 From: pbrookes at redhat.com (Phil Brookes) Date: Wed, 13 Dec 2017 09:31:24 +0000 Subject: [feedhenry-dev] prometheus demo In-Reply-To: References: Message-ID: Hey Craig, Yeah, that?s right. The Prometheus user needs namespace view permission for the service discovery to function, which the APB is able to add automatically. ? On Wed, Dec 13, 2017 at 9:04 AM, Craig Brookes wrote: > Nice video was that all setup with no need for additional perms? > > -- > Craig Brookes > RHMAP > @maleck13 Github > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Wed Dec 13 09:36:54 2017 From: davmarti at redhat.com (David Martin) Date: Wed, 13 Dec 2017 09:36:54 +0000 Subject: [feedhenry-dev] APB service provision using secrets and configmaps and proposals in general In-Reply-To: References: Message-ID: including aerogear-dev On 13 December 2017 at 08:55, Craig Brookes wrote: > Hey guys, > > *tldr* > *- Use a combination of configmaps and secrets to store public (ie client > config) vs secret (ie credentials) when provisioning services via an APB* > *- Use proposals for these kind of changes (ie where they are larger > changes, breaking changes or changes in technical direction that have cross > cutting concerns.)* > *- As we have many pieces, setup aerogear/proposals repo.* > > I would like to suggest that we make use of a mixture of configmap and > secrets during the provision of a mobile "aware" service. > Currently when we provision a service we must also create a secret with a > label: mobile:enabled and at least two pieces of information: > - uri > - name > but it often contains more (such as username and password etc) > This secret is used by the UI to represent that the service is present in > the namespace and to display the credential information that allows the > developer to sign into the service. > During the PoC this secret was also used to populate the mobile client > config. This meant filtering out fields that we did not want the mobile > client to have access to. > My suggestion is that we move to using an additional configmap labeled > "mobile:enabled" that contains the public information that can be exposed > to the mobile client as configuration and a secret still labeled > "mobile:enabled" to capture other information such as the credentials for > logging into the service. > > This really amounts to a proposal. Which brings me to the second > question. Where to keep proposals? I would like us to standardise on have a > public record of technical changes. These proposals should capture the > following: > 1) What > 2) Why > 3) How > As an example here is a proposal that I put together for the ansible > service broker: > https://github.com/openshift/ansible-service-broker/blob/ > master/docs/proposals/last-operation-description.md > This shows the kind of level of detail that I believe we should be > capturing. > When is a proposal necessary? In my experience they are often used for > larger changes, breaking changes or changes in technical direction that > have cross cutting concerns. So in the case of my change outlined above, it > is a breaking change that both the CLI and UI need to be aware of along > with the developers of service APBs and so it should be a proposal. > In the ansible service broker case the proposal is kept in the docs dir of > the repo, however for something larger like Kubernetes they have a separate > repo https://github.com/kubernetes/community. > We could do something similar: aerogear/proposals with directories for > each area > - core > - ui > - cli > - ide-extenstions > - services > - apbs > - push > - sync > ... > > I think this would allow the owner or gatekeeper of the proposal to be > clearly identified. > > Interested in hearing thoughts and opinions > > > > -- > Craig Brookes > RHMAP > @maleck13 Github > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Wed Dec 13 09:50:24 2017 From: davmarti at redhat.com (David Martin) Date: Wed, 13 Dec 2017 09:50:24 +0000 Subject: [feedhenry-dev] Service Catalog Intro video Message-ID: This is a great intro for anyone not familiar with the kubernetes service catalog & brokers. https://www.youtube.com/watch?v=0aLqc-o256w The service catalog calls out to a broker (e.g. the Ansible Service Broker) to provision things. The Ansible Service Broker kicks off an Ansible Playbook Bundle (e.g. unifiedpush-apb, fh-sync-server-apb) to actually do the provisioning steps. -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From weil at redhat.com Wed Dec 13 10:34:39 2017 From: weil at redhat.com (Wei Li) Date: Wed, 13 Dec 2017 10:34:39 +0000 Subject: [feedhenry-dev] Service Catalog Intro video In-Reply-To: References: Message-ID: Thanks for sharing Dave. Great video, explains service catalog very well from a high level. On Wed, Dec 13, 2017 at 9:50 AM, David Martin wrote: > This is a great intro for anyone not familiar with the kubernetes service > catalog & brokers. > > https://www.youtube.com/watch?v=0aLqc-o256w > > The service catalog calls out to a broker (e.g. the Ansible Service > Broker) to provision things. > > The Ansible Service Broker kicks off an Ansible Playbook Bundle (e.g. > unifiedpush-apb, fh-sync-server-apb) to actually do the provisioning steps. > > > -- > 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 > > -- WEI LI SENIOR SOFTWARE ENGINEER Red Hat Mobile weil at redhat.com M: +353862393272 -------------- next part -------------- An HTML attachment was scrubbed... URL: From weil at redhat.com Wed Dec 13 10:48:42 2017 From: weil at redhat.com (Wei Li) Date: Wed, 13 Dec 2017 10:48:42 +0000 Subject: [feedhenry-dev] APB service provision using secrets and configmaps and proposals in general In-Reply-To: References: Message-ID: Please see my comments inline. On Wed, Dec 13, 2017 at 9:36 AM, David Martin wrote: > including aerogear-dev > > On 13 December 2017 at 08:55, Craig Brookes wrote: > >> Hey guys, >> >> *tldr* >> *- Use a combination of configmaps and secrets to store public (ie client >> config) vs secret (ie credentials) when provisioning services via an APB* >> *- Use proposals for these kind of changes (ie where they are larger >> changes, breaking changes or changes in technical direction that have cross >> cutting concerns.)* >> *- As we have many pieces, setup aerogear/proposals repo.* >> >> I would like to suggest that we make use of a mixture of configmap and >> secrets during the provision of a mobile "aware" service. >> Currently when we provision a service we must also create a secret with a >> label: mobile:enabled and at least two pieces of information: >> - uri >> - name >> but it often contains more (such as username and password etc) >> This secret is used by the UI to represent that the service is present in >> the namespace and to display the credential information that allows the >> developer to sign into the service. >> During the PoC this secret was also used to populate the mobile client >> config. This meant filtering out fields that we did not want the mobile >> client to have access to. >> My suggestion is that we move to using an additional configmap labeled >> "mobile:enabled" that contains the public information that can be exposed >> to the mobile client as configuration and a secret still labeled >> "mobile:enabled" to capture other information such as the credentials for >> logging into the service. >> >> +1. This is a quote I found from the author of both secret & configmap: > 1. Use secrets for things which are actually secret like API keys, > credentials, etc > 2. Use config map for not-secret configuration data > > So the proposed change is well aligned with this statement. > This really amounts to a proposal. Which brings me to the second >> question. Where to keep proposals? I would like us to standardise on have a >> public record of technical changes. These proposals should capture the >> following: >> 1) What >> 2) Why >> 3) How >> As an example here is a proposal that I put together for the ansible >> service broker: >> https://github.com/openshift/ansible-service-broker/blob/mas >> ter/docs/proposals/last-operation-description.md >> This shows the kind of level of detail that I believe we should be >> capturing. >> When is a proposal necessary? In my experience they are often used for >> larger changes, breaking changes or changes in technical direction that >> have cross cutting concerns. So in the case of my change outlined above, it >> is a breaking change that both the CLI and UI need to be aware of along >> with the developers of service APBs and so it should be a proposal. >> In the ansible service broker case the proposal is kept in the docs dir >> of the repo, however for something larger like Kubernetes they have a >> separate repo https://github.com/kubernetes/community. >> We could do something similar: aerogear/proposals with directories for >> each area >> - core >> - ui >> - cli >> - ide-extenstions >> - services >> - apbs >> - push >> - sync >> ... >> > +1 on creating a repo for the proposals. I also want to add sometimes there are a few options on the 'How'. In that case, it's important to list all the options and explain why one of them is being chosen. We probably also want to capture the status of the proposal - e.g. accepted, rejected, work in progress or completed etc so that community members can easily find out what have been done and what haven't. > >> I think this would allow the owner or gatekeeper of the proposal to be >> clearly identified. >> >> Interested in hearing thoughts and opinions >> >> >> >> -- >> Craig Brookes >> RHMAP >> @maleck13 Github >> >> _______________________________________________ >> 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 > > -- WEI LI SENIOR SOFTWARE ENGINEER Red Hat Mobile weil at redhat.com M: +353862393272 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbrookes at redhat.com Wed Dec 13 13:27:08 2017 From: cbrookes at redhat.com (Craig Brookes) Date: Wed, 13 Dec 2017 13:27:08 +0000 Subject: [feedhenry-dev] APB service provision using secrets and configmaps and proposals in general In-Reply-To: References: Message-ID: Great. Lets use this is a discussion point for thurday's call On Wed, Dec 13, 2017 at 10:48 AM, Wei Li wrote: > Please see my comments inline. > > On Wed, Dec 13, 2017 at 9:36 AM, David Martin wrote: > >> including aerogear-dev >> >> On 13 December 2017 at 08:55, Craig Brookes wrote: >> >>> Hey guys, >>> >>> *tldr* >>> *- Use a combination of configmaps and secrets to store public (ie >>> client config) vs secret (ie credentials) when provisioning services via an >>> APB* >>> *- Use proposals for these kind of changes (ie where they are larger >>> changes, breaking changes or changes in technical direction that have cross >>> cutting concerns.)* >>> *- As we have many pieces, setup aerogear/proposals repo.* >>> >>> I would like to suggest that we make use of a mixture of configmap and >>> secrets during the provision of a mobile "aware" service. >>> Currently when we provision a service we must also create a secret with >>> a label: mobile:enabled and at least two pieces of information: >>> - uri >>> - name >>> but it often contains more (such as username and password etc) >>> This secret is used by the UI to represent that the service is present >>> in the namespace and to display the credential information that allows the >>> developer to sign into the service. >>> During the PoC this secret was also used to populate the mobile client >>> config. This meant filtering out fields that we did not want the mobile >>> client to have access to. >>> My suggestion is that we move to using an additional configmap labeled >>> "mobile:enabled" that contains the public information that can be exposed >>> to the mobile client as configuration and a secret still labeled >>> "mobile:enabled" to capture other information such as the credentials for >>> logging into the service. >>> >>> > +1. This is a quote I found from the author of both secret & configmap: > > >> 1. Use secrets for things which are actually secret like API keys, >> credentials, etc >> 2. Use config map for not-secret configuration data >> >> So the proposed change is well aligned with this statement. > > >> This really amounts to a proposal. Which brings me to the second >>> question. Where to keep proposals? I would like us to standardise on have a >>> public record of technical changes. These proposals should capture the >>> following: >>> 1) What >>> 2) Why >>> 3) How >>> As an example here is a proposal that I put together for the ansible >>> service broker: >>> https://github.com/openshift/ansible-service-broker/blob/mas >>> ter/docs/proposals/last-operation-description.md >>> This shows the kind of level of detail that I believe we should be >>> capturing. >>> When is a proposal necessary? In my experience they are often used for >>> larger changes, breaking changes or changes in technical direction that >>> have cross cutting concerns. So in the case of my change outlined above, it >>> is a breaking change that both the CLI and UI need to be aware of along >>> with the developers of service APBs and so it should be a proposal. >>> In the ansible service broker case the proposal is kept in the docs dir >>> of the repo, however for something larger like Kubernetes they have a >>> separate repo https://github.com/kubernetes/community. >>> We could do something similar: aerogear/proposals with directories for >>> each area >>> - core >>> - ui >>> - cli >>> - ide-extenstions >>> - services >>> - apbs >>> - push >>> - sync >>> ... >>> >> > +1 on creating a repo for the proposals. I also want to add sometimes > there are a few options on the 'How'. In that case, it's important to list > all the options and explain why one of them is being chosen. > > We probably also want to capture the status of the proposal - e.g. > accepted, rejected, work in progress or completed etc so that community > members can easily find out what have been done and what haven't. > > >> >>> I think this would allow the owner or gatekeeper of the proposal to be >>> clearly identified. >>> >>> Interested in hearing thoughts and opinions >>> >>> >>> >>> -- >>> Craig Brookes >>> RHMAP >>> @maleck13 Github >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > > WEI LI > > SENIOR SOFTWARE ENGINEER > > Red Hat Mobile > > weil at redhat.com M: +353862393272 > > -- Craig Brookes RHMAP @maleck13 Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbrookes at redhat.com Wed Dec 13 13:36:00 2017 From: cbrookes at redhat.com (Craig Brookes) Date: Wed, 13 Dec 2017 13:36:00 +0000 Subject: [feedhenry-dev] Separate APB org or just separate repo Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Wed Dec 13 13:46:08 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Wed, 13 Dec 2017 14:46:08 +0100 Subject: [feedhenry-dev] Separate APB org or just separate repo In-Reply-To: References: Message-ID: On Wed, Dec 13, 2017 at 2:36 PM, Craig Brookes 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 > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbrookes at redhat.com Wed Dec 13 13:49:09 2017 From: cbrookes at redhat.com (Craig Brookes) Date: Wed, 13 Dec 2017 13:49:09 +0000 Subject: [feedhenry-dev] Separate APB org or just separate repo In-Reply-To: References: Message-ID: what is the advantage of moving the apbs to their own org? On Wed, Dec 13, 2017 at 1:46 PM, Matthias Wessendorf wrote: > > > On Wed, Dec 13, 2017 at 2:36 PM, Craig Brookes > 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 >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > Project lead AeroGear.org > -- Craig Brookes RHMAP @maleck13 Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From supittma at redhat.com Wed Dec 13 13:55:50 2017 From: supittma at redhat.com (Summers Pittman) Date: Wed, 13 Dec 2017 08:55:50 -0500 Subject: [feedhenry-dev] Separate APB org or just separate repo In-Reply-To: References: Message-ID: On Wed, Dec 13, 2017 at 8:46 AM, Matthias Wessendorf wrote: > > > On Wed, Dec 13, 2017 at 2:36 PM, Craig Brookes > 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 >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Wed Dec 13 14:08:18 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Wed, 13 Dec 2017 14:08:18 +0000 Subject: [feedhenry-dev] Separate APB org or just separate repo In-Reply-To: References: Message-ID: On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman wrote: > > > On Wed, Dec 13, 2017 at 8:46 AM, Matthias Wessendorf > wrote: > >> >> >> On Wed, Dec 13, 2017 at 2:36 PM, Craig Brookes >> 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 IM: wtrocki -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfrizell at redhat.com Wed Dec 13 14:14:32 2017 From: jfrizell at redhat.com (John Frizelle) Date: Wed, 13 Dec 2017 14:14:32 +0000 Subject: [feedhenry-dev] Separate APB org or just separate repo In-Reply-To: References: Message-ID: 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 * twitter:* @johnfriz* skype: *john_frizelle* mail: *jfrizell at redhat.com * On 13 December 2017 at 14:08, Wojciech Trocki wrote: > > > On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman > wrote: > >> >> >> On Wed, Dec 13, 2017 at 8:46 AM, Matthias Wessendorf > > wrote: >> >>> >>> >>> On Wed, Dec 13, 2017 at 2:36 PM, Craig Brookes >>> 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 > > IM: wtrocki > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From davmarti at redhat.com Wed Dec 13 14:23:20 2017 From: davmarti at redhat.com (David Martin) Date: Wed, 13 Dec 2017 14:23:20 +0000 Subject: [feedhenry-dev] Separate APB org or just separate repo In-Reply-To: References: Message-ID: 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 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 * > twitter:* @johnfriz* > skype: *john_frizelle* > mail: *jfrizell at redhat.com * > > > > > On 13 December 2017 at 14:08, Wojciech Trocki wrote: > >> >> >> On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman >> 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 >>>> 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 >> >> IM: wtrocki >> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From lgriffin at redhat.com Wed Dec 13 14:26:02 2017 From: lgriffin at redhat.com (Leigh Griffin) Date: Wed, 13 Dec 2017 14:26:02 +0000 Subject: [feedhenry-dev] Anyone else encountering issues with mail delivery on aerogear-dev? In-Reply-To: References: Message-ID: For anyone who has not seen the latest mails on The Core mailing list, there is a known issue with mail delivery delays on lists. Copying a response from one of the admins The issue is there are delays in mail delivery. I manage the mail routing > infrastructure. We are aware of those delays and are working on trying to > resolve them. The solution is rather complicated, but considering the > ongoing issues that were mentioned in the ticket, I wanted to address them > personally. As it's somewhat inconsistent, maybe keep CCing both lists until we get some resolution on the problems that Aerogear-dev seems to have right now. Leigh On Tue, Dec 12, 2017 at 7:00 PM, Leigh Griffin wrote: > Matthias it might be worth logging in as an Admin and checking settings. I > have noticed this over the summer with GSoC and I see some requests get > flagged for mod approval. We have a spam problem (admins see this not the > list) as well so they might get missed in that noise. > > I like Google Groups actually, nice option. > > I'm an Admin as well and can try check Thursday due to QBR tomorrow. If > you had time that would be great. > > Leigh > > On 12 Dec 2017 18:11, "Wojciech Trocki" wrote: > >> +1 for google groups. >> >> Other rht teams already using that. >> >> On 12 Dec 2017 5:12 pm, "Matthias Wessendorf" >> wrote: >> >> I am tempted to ask: is google groups the ultimate fix for this ? :-) >> >> On Tue, Dec 12, 2017 at 6:10 PM, Matthias Wessendorf > > wrote: >> >>> https://redhat.service-now.com/surl.do?n=PNT0067920 >>> >>> On Tue, Dec 12, 2017 at 6:08 PM, Jason Madigan >>> wrote: >>> >>>> >>>> >>>> -- >>>> Jason Madigan >>>> Engineering Manager, Red Hat Mobile >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >>> >>> -- >>> Project lead AeroGear.org >>> >> >> >> >> -- >> 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 >> >> -- LEIGH GRIFFIN ENGINEERING MANAGER, MOBILE Red Hat Ireland Communications House, Cork Road Waterford City, Ireland X91NY33 lgriffin at redhat.com M: +353877545162 IM: lgriffin TRIED. TESTED. TRUSTED. @redhatway @redhatinc @redhatsnaps -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfrizell at redhat.com Wed Dec 13 14:29:46 2017 From: jfrizell at redhat.com (John Frizelle) Date: Wed, 13 Dec 2017 14:29:46 +0000 Subject: [feedhenry-dev] Separate APB org or just separate repo In-Reply-To: References: Message-ID: 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 * twitter:* @johnfriz* skype: *john_frizelle* mail: *jfrizell at redhat.com * On 13 December 2017 at 14:23, David Martin 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 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 * >> twitter:* @johnfriz* >> skype: *john_frizelle* >> mail: *jfrizell at redhat.com * >> >> >> >> >> On 13 December 2017 at 14:08, Wojciech Trocki wrote: >> >>> >>> >>> On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman >>> 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 >>>>> 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 >>> >>> IM: wtrocki >>> >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From jmadigan at redhat.com Wed Dec 13 14:31:32 2017 From: jmadigan at redhat.com (Jason Madigan) Date: Wed, 13 Dec 2017 14:31:32 +0000 Subject: [feedhenry-dev] Anyone else encountering issues with mail delivery on aerogear-dev? In-Reply-To: References: Message-ID: Terrible timing as we're moving comms over to aerogear-dev for a lot of our kick-off talks! Let's hope the issues are resolved soon. On Wed, Dec 13, 2017 at 2:26 PM, Leigh Griffin wrote: > For anyone who has not seen the latest mails on The Core mailing list, > there is a known issue with mail delivery delays on lists. Copying a > response from one of the admins > > The issue is there are delays in mail delivery. I manage the mail routing >> infrastructure. We are aware of those delays and are working on trying to >> resolve them. The solution is rather complicated, but considering the >> ongoing issues that were mentioned in the ticket, I wanted to address them >> personally. > > > As it's somewhat inconsistent, maybe keep CCing both lists until we get > some resolution on the problems that Aerogear-dev seems to have right now. > > Leigh > > On Tue, Dec 12, 2017 at 7:00 PM, Leigh Griffin > wrote: > >> Matthias it might be worth logging in as an Admin and checking settings. >> I have noticed this over the summer with GSoC and I see some requests get >> flagged for mod approval. We have a spam problem (admins see this not the >> list) as well so they might get missed in that noise. >> >> I like Google Groups actually, nice option. >> >> I'm an Admin as well and can try check Thursday due to QBR tomorrow. If >> you had time that would be great. >> >> Leigh >> >> On 12 Dec 2017 18:11, "Wojciech Trocki" wrote: >> >>> +1 for google groups. >>> >>> Other rht teams already using that. >>> >>> On 12 Dec 2017 5:12 pm, "Matthias Wessendorf" >>> wrote: >>> >>> I am tempted to ask: is google groups the ultimate fix for this ? :-) >>> >>> On Tue, Dec 12, 2017 at 6:10 PM, Matthias Wessendorf < >>> mwessend at redhat.com> wrote: >>> >>>> https://redhat.service-now.com/surl.do?n=PNT0067920 >>>> >>>> On Tue, Dec 12, 2017 at 6:08 PM, Jason Madigan >>>> wrote: >>>> >>>>> >>>>> >>>>> -- >>>>> Jason Madigan >>>>> Engineering Manager, Red Hat Mobile >>>>> >>>>> _______________________________________________ >>>>> feedhenry-dev mailing list >>>>> feedhenry-dev at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Project lead AeroGear.org >>>> >>> >>> >>> >>> -- >>> 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 >>> >>> > > > -- > > LEIGH GRIFFIN > > ENGINEERING MANAGER, MOBILE > > Red Hat Ireland > > Communications House, Cork Road > > Waterford City, Ireland X91NY33 > > lgriffin at redhat.com M: +353877545162 IM: lgriffin > > TRIED. TESTED. TRUSTED. > > @redhatway @redhatinc > @redhatsnaps > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- Jason Madigan Engineering Manager, Red Hat Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrookes at redhat.com Wed Dec 13 14:44:02 2017 From: pbrookes at redhat.com (Phil Brookes) Date: Wed, 13 Dec 2017 14:44:02 +0000 Subject: [feedhenry-dev] Separate APB org or just separate repo In-Reply-To: References: Message-ID: ?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 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 * > twitter:* @johnfriz* > skype: *john_frizelle* > mail: *jfrizell at redhat.com * > > > > > On 13 December 2017 at 14:23, David Martin 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 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 * >>> twitter:* @johnfriz* >>> skype: *john_frizelle* >>> mail: *jfrizell at redhat.com * >>> >>> >>> >>> >>> On 13 December 2017 at 14:08, Wojciech Trocki >>> wrote: >>> >>>> >>>> >>>> On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman >>>> 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 >>>>>> 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 >>>> >>>> IM: wtrocki >>>> >>>> >>>> _______________________________________________ >>>> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From supittma at redhat.com Wed Dec 13 14:52:30 2017 From: supittma at redhat.com (Summers Pittman) Date: Wed, 13 Dec 2017 09:52:30 -0500 Subject: [feedhenry-dev] Separate APB org or just separate repo In-Reply-To: References: Message-ID: On Wed, Dec 13, 2017 at 9:29 AM, John Frizelle 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. > > That is the way Google does it, all of their code is in a single repository https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext 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. > [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 * > twitter:* @johnfriz* > skype: *john_frizelle* > mail: *jfrizell at redhat.com * > > > > > On 13 December 2017 at 14:23, David Martin 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 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 * >>> twitter:* @johnfriz* >>> skype: *john_frizelle* >>> mail: *jfrizell at redhat.com * >>> >>> >>> >>> >>> On 13 December 2017 at 14:08, Wojciech Trocki >>> wrote: >>> >>>> >>>> >>>> On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman >>>> 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 >>>>>> 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 >>>> >>>> IM: wtrocki >>>> >>>> >>>> _______________________________________________ >>>> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From mwessend at redhat.com Wed Dec 13 14:54:23 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Wed, 13 Dec 2017 15:54:23 +0100 Subject: [feedhenry-dev] Separate APB org or just separate repo In-Reply-To: References: Message-ID: On Wed, Dec 13, 2017 at 3:44 PM, Phil Brookes 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 > 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 * >> twitter:* @johnfriz* >> skype: *john_frizelle* >> mail: *jfrizell at redhat.com * >> >> >> >> >> On 13 December 2017 at 14:23, David Martin 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 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 * >>>> twitter:* @johnfriz* >>>> skype: *john_frizelle* >>>> mail: *jfrizell at redhat.com * >>>> >>>> >>>> >>>> >>>> On 13 December 2017 at 14:08, Wojciech Trocki >>>> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman >>>>> 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 >>>>>>> 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 >>>>> >>>>> IM: wtrocki >>>>> >>>>> >>>>> _______________________________________________ >>>>> feedhenry-dev mailing list >>>>> feedhenry-dev at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> feedhenry-dev mailing list >>>> feedhenry-dev at redhat.com >>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>> >>>> >>> >>> >>> -- >>> David Martin >>> Red Hat Mobile >>> Twitter: @irldavem >>> IRC: @irldavem (feedhenry, mobile-internal) >>> >> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From mwessend at redhat.com Wed Dec 13 14:55:16 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Wed, 13 Dec 2017 15:55:16 +0100 Subject: [feedhenry-dev] Anyone else encountering issues with mail delivery on aerogear-dev? In-Reply-To: References: Message-ID: On Wed, Dec 13, 2017 at 3:31 PM, Jason Madigan wrote: > Terrible timing as we're moving comms over to aerogear-dev for a lot of > our kick-off talks! Let's hope the issues are resolved soon. > Did you say google-groups ? > > On Wed, Dec 13, 2017 at 2:26 PM, Leigh Griffin > wrote: > >> For anyone who has not seen the latest mails on The Core mailing list, >> there is a known issue with mail delivery delays on lists. Copying a >> response from one of the admins >> >> The issue is there are delays in mail delivery. I manage the mail >>> routing infrastructure. We are aware of those delays and are working on >>> trying to resolve them. The solution is rather complicated, but >>> considering the ongoing issues that were mentioned in the ticket, I wanted >>> to address them personally. >> >> >> As it's somewhat inconsistent, maybe keep CCing both lists until we get >> some resolution on the problems that Aerogear-dev seems to have right now. >> >> Leigh >> >> On Tue, Dec 12, 2017 at 7:00 PM, Leigh Griffin >> wrote: >> >>> Matthias it might be worth logging in as an Admin and checking settings. >>> I have noticed this over the summer with GSoC and I see some requests get >>> flagged for mod approval. We have a spam problem (admins see this not the >>> list) as well so they might get missed in that noise. >>> >>> I like Google Groups actually, nice option. >>> >>> I'm an Admin as well and can try check Thursday due to QBR tomorrow. If >>> you had time that would be great. >>> >>> Leigh >>> >>> On 12 Dec 2017 18:11, "Wojciech Trocki" wrote: >>> >>>> +1 for google groups. >>>> >>>> Other rht teams already using that. >>>> >>>> On 12 Dec 2017 5:12 pm, "Matthias Wessendorf" >>>> wrote: >>>> >>>> I am tempted to ask: is google groups the ultimate fix for this ? :-) >>>> >>>> On Tue, Dec 12, 2017 at 6:10 PM, Matthias Wessendorf < >>>> mwessend at redhat.com> wrote: >>>> >>>>> https://redhat.service-now.com/surl.do?n=PNT0067920 >>>>> >>>>> On Tue, Dec 12, 2017 at 6:08 PM, Jason Madigan >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Jason Madigan >>>>>> Engineering Manager, Red Hat Mobile >>>>>> >>>>>> _______________________________________________ >>>>>> feedhenry-dev mailing list >>>>>> feedhenry-dev at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Project lead AeroGear.org >>>>> >>>> >>>> >>>> >>>> -- >>>> 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 >>>> >>>> >> >> >> -- >> >> LEIGH GRIFFIN >> >> ENGINEERING MANAGER, MOBILE >> >> Red Hat Ireland >> >> Communications House, Cork Road >> >> Waterford City, Ireland X91NY33 >> >> lgriffin at redhat.com M: +353877545162 IM: lgriffin >> >> TRIED. TESTED. TRUSTED. >> >> @redhatway @redhatinc >> @redhatsnaps >> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > Jason Madigan > Engineering Manager, Red Hat Mobile > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From stobin at redhat.com Wed Dec 13 15:42:17 2017 From: stobin at redhat.com (Steven Tobin) Date: Wed, 13 Dec 2017 15:42:17 +0000 Subject: [feedhenry-dev] Anyone else encountering issues with mail delivery on aerogear-dev? In-Reply-To: References: Message-ID: Yeah i'm apparently not getting any messages from aergear-dev. Nothing since 14:00 yesterday. On Wed, Dec 13, 2017 at 2:55 PM, Matthias Wessendorf wrote: > > > On Wed, Dec 13, 2017 at 3:31 PM, Jason Madigan > wrote: > >> Terrible timing as we're moving comms over to aerogear-dev for a lot of >> our kick-off talks! Let's hope the issues are resolved soon. >> > > Did you say google-groups ? > > >> >> On Wed, Dec 13, 2017 at 2:26 PM, Leigh Griffin >> wrote: >> >>> For anyone who has not seen the latest mails on The Core mailing list, >>> there is a known issue with mail delivery delays on lists. Copying a >>> response from one of the admins >>> >>> The issue is there are delays in mail delivery. I manage the mail >>>> routing infrastructure. We are aware of those delays and are working on >>>> trying to resolve them. The solution is rather complicated, but >>>> considering the ongoing issues that were mentioned in the ticket, I wanted >>>> to address them personally. >>> >>> >>> As it's somewhat inconsistent, maybe keep CCing both lists until we get >>> some resolution on the problems that Aerogear-dev seems to have right now. >>> >>> Leigh >>> >>> On Tue, Dec 12, 2017 at 7:00 PM, Leigh Griffin >>> wrote: >>> >>>> Matthias it might be worth logging in as an Admin and checking >>>> settings. I have noticed this over the summer with GSoC and I see some >>>> requests get flagged for mod approval. We have a spam problem (admins see >>>> this not the list) as well so they might get missed in that noise. >>>> >>>> I like Google Groups actually, nice option. >>>> >>>> I'm an Admin as well and can try check Thursday due to QBR tomorrow. If >>>> you had time that would be great. >>>> >>>> Leigh >>>> >>>> On 12 Dec 2017 18:11, "Wojciech Trocki" wrote: >>>> >>>>> +1 for google groups. >>>>> >>>>> Other rht teams already using that. >>>>> >>>>> On 12 Dec 2017 5:12 pm, "Matthias Wessendorf" >>>>> wrote: >>>>> >>>>> I am tempted to ask: is google groups the ultimate fix for this ? :-) >>>>> >>>>> On Tue, Dec 12, 2017 at 6:10 PM, Matthias Wessendorf < >>>>> mwessend at redhat.com> wrote: >>>>> >>>>>> https://redhat.service-now.com/surl.do?n=PNT0067920 >>>>>> >>>>>> On Tue, Dec 12, 2017 at 6:08 PM, Jason Madigan >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Jason Madigan >>>>>>> Engineering Manager, Red Hat Mobile >>>>>>> >>>>>>> _______________________________________________ >>>>>>> feedhenry-dev mailing list >>>>>>> feedhenry-dev at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Project lead AeroGear.org >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>>> >>>>> >>> >>> >>> -- >>> >>> LEIGH GRIFFIN >>> >>> ENGINEERING MANAGER, MOBILE >>> >>> Red Hat Ireland >>> >>> Communications House, Cork Road >>> >>> Waterford City, Ireland X91NY33 >>> >>> lgriffin at redhat.com M: +353877545162 IM: lgriffin >>> >>> TRIED. TESTED. TRUSTED. >>> >>> @redhatway @redhatinc >>> @redhatsnaps >>> >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> Jason Madigan >> Engineering Manager, Red Hat Mobile >> >> _______________________________________________ >> 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 > > -- Regards, Steven Tobin STEVEN TOBIN ASSOCIATE CLOUD OPERATIONS ENGINEER Red Hat Mobile Communications House Cork Road, Waterford stobin at redhat.com T: 35351810155 IM: @stobin TRIED. TESTED. TRUSTED. @redhatway @redhatinc @redhatsnaps -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Wed Dec 13 15:59:47 2017 From: davmarti at redhat.com (David Martin) Date: Wed, 13 Dec 2017 15:59:47 +0000 Subject: [feedhenry-dev] mobile client or mobile app In-Reply-To: References: <4cd1277c-7043-2770-4b2c-8e1df071b49e@redhat.com> Message-ID: I thought this was interesting. Chris Shinn (UX) came up with the term 'Mobile Client Build' in UI mockups for mobile apps on the OpenShift overview screen. This was to make it obvious we're talking about 'Mobile' builds rather than typical S2I or Docker builds. [image: Inline images 1] On 30 November 2017 at 14:13, Matthias Wessendorf wrote: > I like that - and is similar to UPS terminology :) > > > > On Thu, Nov 30, 2017 at 2:23 PM, John Frizelle > wrote: > >> perhaps "construct" instead of "container configuration" >> >> MobileClient: A construct that represents the overall mobile application >> on OpenShift (eg MobileHR) >> >> >> -- >> John Frizelle >> Chief Architect, Red Hat Mobile >> Consulting Engineer >> >> mobile: *+353 87 290 1644 * >> twitter:* @johnfriz* >> skype: *john_frizelle* >> mail: *jfrizell at redhat.com * >> >> >> >> >> On 30 November 2017 at 11:48, Matthias Wessendorf >> wrote: >> >>> >>> >>> On Thu, Nov 30, 2017 at 12:05 PM, Paul Wright >>> wrote: >>> >>>> last comment, then I'll stop (promise): >>>> >>>> Let's go with MobileClient, as discussed below, but take a bit more >>>> time about the definition. >>>> >>>> I think the definition for PushApplication is great in the context of >>>> UPS, but with MCP, we're trying to explain an item that is front and >>>> center, and that the user might misunderstand, or not act as expected. >>>> >>>> Can we be more explicit and give an example? >>>> >>>> - MobileClient: A container configuration that represents the overall >>>> mobile application on OpenShift (eg MobileHR) >>>> >>> >>> container ... hrm - not sure - that's also misleading... ?! >>> >>> >>> >>>> >>>> >>>> Paul >>>> >>>> On 11/30/2017 10:26 AM, Matthias Wessendorf wrote: >>>> >>>> +1 on something like "logical construct / logical representation" - >>>> and right UPS has also had some naming struggles :) >>>> >>>> On Thu, Nov 30, 2017 at 11:11 AM, David Martin >>>> wrote: >>>> >>>>> The term 'Resource' may not suit as it has a meaning in the Kubernetes >>>>> world. >>>>> Any object that kubernetes exposes an API for is a resource e.g. >>>>> Secrets, Pods, Deployments are all resources. >>>>> >>>>> In UPS, there's the idea of a 'Push Application', defined here [1] >>>>> "PushApplication >>>>> A logical construct that represents an overall mobile application" >>>>> >>>>> I don't see any problem with giving it a name like 'Mobile Client' and >>>>> calling it out in terminology in a similar manner >>>>> "MobileClient >>>>> A logical construct that represents an overall mobile application" >>>>> >>>>> [1] https://aerogear.org/docs/unifiedpush/ups_userguide/inde >>>>> x/#_useful_terminology >>>>> >>>>> On 29 November 2017 at 09:42, Paul Wright wrote: >>>>> >>>>>> and that conversation makes me think we need to be more descriptive, >>>>>> eg >>>>>> >>>>>> Mobile App Resource Client (MARC) >>>>>> >>>>>> Paul >>>>>> >>>>>> On 11/29/2017 09:38 AM, Craig Brookes wrote: >>>>>> >>>>>> Spoke with Paul offline. And he thought we were referring to mobile >>>>>> app through out our docs. So to clarify I meant with the context of the mcp >>>>>> UI and CLI. >>>>>> >>>>>> On Mon, Nov 27, 2017 at 11:49 AM, Paul Wright >>>>>> wrote: >>>>>> >>>>>>> It seems to me that to tackle the mobile market, we should embrace >>>>>>> the lingua franca, and the one word that unites mobile,cell phone, >>>>>>> smartphone, handys, etc is 'App' >>>>>>> >>>>>>> Paul >>>>>>> my original draft reply: >>>>>>> >>>>>>> Mondays... >>>>>>> >>>>>>> Let's fix everything >>>>>>> >>>>>>> I'm not against this change, but would like to throw in a note of >>>>>>> caution: >>>>>>> >>>>>>> 1. I don't think OpenShift are really pushing the term apps. Sure, >>>>>>> there's a command, and even some doc references ( >>>>>>> https://access.redhat.com/documentation/en-us/openshift_ent >>>>>>> erprise/3.2/html/installation_and_configuration/install-conf >>>>>>> ig-imagestreams-templates#creating-instantapp-templates), but would >>>>>>> like to check with them before assuming that's deliberate. In my mind, >>>>>>> their term of choice is Application, a bit more of an enterprisey term. >>>>>>> >>>>>>> 2. Does "Mobile Clients" solve a problem? we already have a >>>>>>> generation of ppl saying "there's an app for that", do we want to embrace >>>>>>> that or swim upstream? what about when there's a web ui to something, we >>>>>>> used to bundle mobile and web into the term 'client app'. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 11/27/2017 11:03 AM, Jason Madigan wrote: >>>>>>> >>>>>>> Deep thoughts this early in the week. App is quite a loaded term >>>>>>> alright, particularly in an OpenShift context, so I think Mobile Client may >>>>>>> be a clearer distinction. >>>>>>> >>>>>>> Looping in our wordsmith Paul who may have other ideas. >>>>>>> >>>>>>> On Mon, Nov 27, 2017 at 9:44 AM, Craig Brookes >>>>>>> wrote: >>>>>>> >>>>>>>> Was thinking about terminology . We have been using the term mobile >>>>>>>> app, but I wonder would it be clearer to use the term mobile client >>>>>>>> instead. >>>>>>>> The main reason for this is that app can mean a server side >>>>>>>> component (in OpenShift there is the new-app command for example). I think >>>>>>>> it would make a clearer distinction. Another example is around the word >>>>>>>> build. When you do an app build in OpenShift it normally produces a docker >>>>>>>> image and a running server / app. I think using the the term mobile client >>>>>>>> build makes it clearer what is happening. >>>>>>>> >>>>>>>> Just a thought for a Monday morning. >>>>>>>> >>>>>>>> -- >>>>>>>> Craig Brookes >>>>>>>> RHMAP >>>>>>>> @maleck13 Github >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> feedhenry-dev mailing list >>>>>>>> feedhenry-dev at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Jason Madigan >>>>>>> Engineering Manager, Red Hat Mobile >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Craig Brookes >>>>>> RHMAP >>>>>> @maleck13 Github >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> Project lead AeroGear.org >>>> >>>> >>>> >>> >>> >>> -- >>> Project lead AeroGear.org >>> >>> _______________________________________________ >>> 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 > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 70585 bytes Desc: not available URL: From cshinn at redhat.com Wed Dec 13 16:28:52 2017 From: cshinn at redhat.com (Chris Shinn) Date: Wed, 13 Dec 2017 08:28:52 -0800 Subject: [feedhenry-dev] mobile client or mobile app In-Reply-To: References: <4cd1277c-7043-2770-4b2c-8e1df071b49e@redhat.com> Message-ID: That said, I do think that there?s value in ?app?. Especially because of its ubiquity, it?s likely to be the ?search term" that people are looking for when they are trying to find parts of the interface that are relevant to their current task. On December 13, 2017 at 10:59:54 AM, David Martin (davmarti at redhat.com) wrote: I thought this was interesting. Chris Shinn (UX) came up with the term 'Mobile Client Build' in UI mockups for mobile apps on the OpenShift overview screen. This was to make it obvious we're talking about 'Mobile' builds rather than typical S2I or Docker builds. [image: Inline images 1] On 30 November 2017 at 14:13, Matthias Wessendorf wrote: > I like that - and is similar to UPS terminology :) > > > > On Thu, Nov 30, 2017 at 2:23 PM, John Frizelle > wrote: > >> perhaps "construct" instead of "container configuration" >> >> MobileClient: A construct that represents the overall mobile application >> on OpenShift (eg MobileHR) >> >> >> -- >> John Frizelle >> Chief Architect, Red Hat Mobile >> Consulting Engineer >> >> mobile: *+353 87 290 1644 * >> twitter:* @johnfriz* >> skype: *john_frizelle* >> mail: *jfrizell at redhat.com * >> >> >> >> >> On 30 November 2017 at 11:48, Matthias Wessendorf >> wrote: >> >>> >>> >>> On Thu, Nov 30, 2017 at 12:05 PM, Paul Wright >>> wrote: >>> >>>> last comment, then I'll stop (promise): >>>> >>>> Let's go with MobileClient, as discussed below, but take a bit more >>>> time about the definition. >>>> >>>> I think the definition for PushApplication is great in the context of >>>> UPS, but with MCP, we're trying to explain an item that is front and >>>> center, and that the user might misunderstand, or not act as expected. >>>> >>>> Can we be more explicit and give an example? >>>> >>>> - MobileClient: A container configuration that represents the overall >>>> mobile application on OpenShift (eg MobileHR) >>>> >>> >>> container ... hrm - not sure - that's also misleading... ?! >>> >>> >>> >>>> >>>> >>>> Paul >>>> >>>> On 11/30/2017 10:26 AM, Matthias Wessendorf wrote: >>>> >>>> +1 on something like "logical construct / logical representation" - >>>> and right UPS has also had some naming struggles :) >>>> >>>> On Thu, Nov 30, 2017 at 11:11 AM, David Martin >>>> wrote: >>>> >>>>> The term 'Resource' may not suit as it has a meaning in the Kubernetes >>>>> world. >>>>> Any object that kubernetes exposes an API for is a resource e.g. >>>>> Secrets, Pods, Deployments are all resources. >>>>> >>>>> In UPS, there's the idea of a 'Push Application', defined here [1] >>>>> "PushApplication >>>>> A logical construct that represents an overall mobile application" >>>>> >>>>> I don't see any problem with giving it a name like 'Mobile Client' and >>>>> calling it out in terminology in a similar manner >>>>> "MobileClient >>>>> A logical construct that represents an overall mobile application" >>>>> >>>>> [1] https://aerogear.org/docs/unifiedpush/ups_userguide/inde >>>>> x/#_useful_terminology >>>>> >>>>> On 29 November 2017 at 09:42, Paul Wright wrote: >>>>> >>>>>> and that conversation makes me think we need to be more descriptive, >>>>>> eg >>>>>> >>>>>> Mobile App Resource Client (MARC) >>>>>> >>>>>> Paul >>>>>> >>>>>> On 11/29/2017 09:38 AM, Craig Brookes wrote: >>>>>> >>>>>> Spoke with Paul offline. And he thought we were referring to mobile >>>>>> app through out our docs. So to clarify I meant with the context of the mcp >>>>>> UI and CLI. >>>>>> >>>>>> On Mon, Nov 27, 2017 at 11:49 AM, Paul Wright >>>>>> wrote: >>>>>> >>>>>>> It seems to me that to tackle the mobile market, we should embrace >>>>>>> the lingua franca, and the one word that unites mobile,cell phone, >>>>>>> smartphone, handys, etc is 'App' >>>>>>> >>>>>>> Paul >>>>>>> my original draft reply: >>>>>>> >>>>>>> Mondays... >>>>>>> >>>>>>> Let's fix everything >>>>>>> >>>>>>> I'm not against this change, but would like to throw in a note of >>>>>>> caution: >>>>>>> >>>>>>> 1. I don't think OpenShift are really pushing the term apps. Sure, >>>>>>> there's a command, and even some doc references ( >>>>>>> https://access.redhat.com/documentation/en-us/openshift_ent >>>>>>> erprise/3.2/html/installation_and_configuration/install-conf >>>>>>> ig-imagestreams-templates#creating-instantapp-templates), but would >>>>>>> like to check with them before assuming that's deliberate. In my mind, >>>>>>> their term of choice is Application, a bit more of an enterprisey term. >>>>>>> >>>>>>> 2. Does "Mobile Clients" solve a problem? we already have a >>>>>>> generation of ppl saying "there's an app for that", do we want to embrace >>>>>>> that or swim upstream? what about when there's a web ui to something, we >>>>>>> used to bundle mobile and web into the term 'client app'. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 11/27/2017 11:03 AM, Jason Madigan wrote: >>>>>>> >>>>>>> Deep thoughts this early in the week. App is quite a loaded term >>>>>>> alright, particularly in an OpenShift context, so I think Mobile Client may >>>>>>> be a clearer distinction. >>>>>>> >>>>>>> Looping in our wordsmith Paul who may have other ideas. >>>>>>> >>>>>>> On Mon, Nov 27, 2017 at 9:44 AM, Craig Brookes >>>>>>> wrote: >>>>>>> >>>>>>>> Was thinking about terminology . We have been using the term mobile >>>>>>>> app, but I wonder would it be clearer to use the term mobile client >>>>>>>> instead. >>>>>>>> The main reason for this is that app can mean a server side >>>>>>>> component (in OpenShift there is the new-app command for example). I think >>>>>>>> it would make a clearer distinction. Another example is around the word >>>>>>>> build. When you do an app build in OpenShift it normally produces a docker >>>>>>>> image and a running server / app. I think using the the term mobile client >>>>>>>> build makes it clearer what is happening. >>>>>>>> >>>>>>>> Just a thought for a Monday morning. >>>>>>>> >>>>>>>> -- >>>>>>>> Craig Brookes >>>>>>>> RHMAP >>>>>>>> @maleck13 Github >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> feedhenry-dev mailing list >>>>>>>> feedhenry-dev at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Jason Madigan >>>>>>> Engineering Manager, Red Hat Mobile >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Craig Brookes >>>>>> RHMAP >>>>>> @maleck13 Github >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>> >>>> >>>> -- >>>> Project lead AeroGear.org >>>> >>>> >>>> >>> >>> >>> -- >>> Project lead AeroGear.org >>> >>> _______________________________________________ >>> 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 > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1deff70600823b9ebf187fa9e94df6ff10966d4e at zimbra Type: application/octet-stream Size: 11472 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ii_1605098c9cd61c41 Type: application/octet-stream Size: 70585 bytes Desc: not available URL: From weil at redhat.com Wed Dec 13 16:34:05 2017 From: weil at redhat.com (Wei Li) Date: Wed, 13 Dec 2017 16:34:05 +0000 Subject: [feedhenry-dev] Separate APB org or just separate repo In-Reply-To: References: Message-ID: 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 wrote: > > > On Wed, Dec 13, 2017 at 3:44 PM, Phil Brookes 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 >> 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 * >>> twitter:* @johnfriz* >>> skype: *john_frizelle* >>> mail: *jfrizell at redhat.com * >>> >>> >>> >>> >>> On 13 December 2017 at 14:23, David Martin 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 >>>> 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 * >>>>> twitter:* @johnfriz* >>>>> skype: *john_frizelle* >>>>> mail: *jfrizell at redhat.com * >>>>> >>>>> >>>>> >>>>> >>>>> On 13 December 2017 at 14:08, Wojciech Trocki >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman >>>>> > 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 >>>>>>> > 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 >>>>>> >>>>>> IM: wtrocki >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 weil at redhat.com M: +353862393272 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From mwessend at redhat.com Wed Dec 13 16:36:19 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Wed, 13 Dec 2017 17:36:19 +0100 Subject: [feedhenry-dev] mobile client or mobile app In-Reply-To: References: <4cd1277c-7043-2770-4b2c-8e1df071b49e@redhat.com> Message-ID: mobile app build ? On Wed, Dec 13, 2017 at 5:28 PM, Chris Shinn wrote: > That said, I do think that there?s value in ?app?. Especially because of > its ubiquity, it?s likely to be the ?search term" that people are looking > for when they are trying to find parts of the interface that are relevant > to their current task. > > > On December 13, 2017 at 10:59:54 AM, David Martin (davmarti at redhat.com) > wrote: > > I thought this was interesting. > > Chris Shinn (UX) came up with the term 'Mobile Client Build' in UI mockups > for mobile apps on the OpenShift overview screen. > This was to make it obvious we're talking about 'Mobile' builds rather > than typical S2I or Docker builds. > > > > [image: Inline images 1] > > On 30 November 2017 at 14:13, Matthias Wessendorf > wrote: > >> I like that - and is similar to UPS terminology :) >> >> >> >> On Thu, Nov 30, 2017 at 2:23 PM, John Frizelle >> wrote: >> >>> perhaps "construct" instead of "container configuration" >>> >>> MobileClient: A construct that represents the overall mobile application >>> on OpenShift (eg MobileHR) >>> >>> >>> -- >>> John Frizelle >>> Chief Architect, Red Hat Mobile >>> Consulting Engineer >>> >>> mobile: *+353 87 290 1644 * >>> twitter:* @johnfriz* >>> skype: *john_frizelle* >>> mail: *jfrizell at redhat.com * >>> >>> >>> >>> >>> On 30 November 2017 at 11:48, Matthias Wessendorf >>> wrote: >>> >>>> >>>> >>>> On Thu, Nov 30, 2017 at 12:05 PM, Paul Wright >>>> wrote: >>>> >>>>> last comment, then I'll stop (promise): >>>>> >>>>> Let's go with MobileClient, as discussed below, but take a bit more >>>>> time about the definition. >>>>> >>>>> I think the definition for PushApplication is great in the context of >>>>> UPS, but with MCP, we're trying to explain an item that is front and >>>>> center, and that the user might misunderstand, or not act as expected. >>>>> >>>>> Can we be more explicit and give an example? >>>>> >>>>> - MobileClient: A container configuration that represents the overall >>>>> mobile application on OpenShift (eg MobileHR) >>>>> >>>> >>>> container ... hrm - not sure - that's also misleading... ?! >>>> >>>> >>>> >>>>> >>>>> >>>>> Paul >>>>> >>>>> On 11/30/2017 10:26 AM, Matthias Wessendorf wrote: >>>>> >>>>> +1 on something like "logical construct / logical representation" - >>>>> and right UPS has also had some naming struggles :) >>>>> >>>>> On Thu, Nov 30, 2017 at 11:11 AM, David Martin >>>>> wrote: >>>>> >>>>>> The term 'Resource' may not suit as it has a meaning in the >>>>>> Kubernetes world. >>>>>> Any object that kubernetes exposes an API for is a resource e.g. >>>>>> Secrets, Pods, Deployments are all resources. >>>>>> >>>>>> In UPS, there's the idea of a 'Push Application', defined here [1] >>>>>> "PushApplication >>>>>> A logical construct that represents an overall mobile application" >>>>>> >>>>>> I don't see any problem with giving it a name like 'Mobile Client' >>>>>> and calling it out in terminology in a similar manner >>>>>> "MobileClient >>>>>> A logical construct that represents an overall mobile application" >>>>>> >>>>>> [1] https://aerogear.org/docs/unifiedpush/ups_userguide/inde >>>>>> x/#_useful_terminology >>>>>> >>>>>> On 29 November 2017 at 09:42, Paul Wright wrote: >>>>>> >>>>>>> and that conversation makes me think we need to be more descriptive, >>>>>>> eg >>>>>>> >>>>>>> Mobile App Resource Client (MARC) >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> On 11/29/2017 09:38 AM, Craig Brookes wrote: >>>>>>> >>>>>>> Spoke with Paul offline. And he thought we were referring to mobile >>>>>>> app through out our docs. So to clarify I meant with the context of the mcp >>>>>>> UI and CLI. >>>>>>> >>>>>>> On Mon, Nov 27, 2017 at 11:49 AM, Paul Wright >>>>>>> wrote: >>>>>>> >>>>>>>> It seems to me that to tackle the mobile market, we should embrace >>>>>>>> the lingua franca, and the one word that unites mobile,cell phone, >>>>>>>> smartphone, handys, etc is 'App' >>>>>>>> >>>>>>>> Paul >>>>>>>> my original draft reply: >>>>>>>> >>>>>>>> Mondays... >>>>>>>> >>>>>>>> Let's fix everything >>>>>>>> >>>>>>>> I'm not against this change, but would like to throw in a note of >>>>>>>> caution: >>>>>>>> >>>>>>>> 1. I don't think OpenShift are really pushing the term apps. Sure, >>>>>>>> there's a command, and even some doc references ( >>>>>>>> https://access.redhat.com/documentation/en-us/openshift_ent >>>>>>>> erprise/3.2/html/installation_and_configuration/install-conf >>>>>>>> ig-imagestreams-templates#creating-instantapp-templates), but >>>>>>>> would like to check with them before assuming that's deliberate. In my >>>>>>>> mind, their term of choice is Application, a bit more of an enterprisey >>>>>>>> term. >>>>>>>> >>>>>>>> 2. Does "Mobile Clients" solve a problem? we already have a >>>>>>>> generation of ppl saying "there's an app for that", do we want to embrace >>>>>>>> that or swim upstream? what about when there's a web ui to something, we >>>>>>>> used to bundle mobile and web into the term 'client app'. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 11/27/2017 11:03 AM, Jason Madigan wrote: >>>>>>>> >>>>>>>> Deep thoughts this early in the week. App is quite a loaded term >>>>>>>> alright, particularly in an OpenShift context, so I think Mobile Client may >>>>>>>> be a clearer distinction. >>>>>>>> >>>>>>>> Looping in our wordsmith Paul who may have other ideas. >>>>>>>> >>>>>>>> On Mon, Nov 27, 2017 at 9:44 AM, Craig Brookes >>>>>>> > wrote: >>>>>>>> >>>>>>>>> Was thinking about terminology . We have been using the term >>>>>>>>> mobile app, but I wonder would it be clearer to use the term mobile client >>>>>>>>> instead. >>>>>>>>> The main reason for this is that app can mean a server side >>>>>>>>> component (in OpenShift there is the new-app command for example). I think >>>>>>>>> it would make a clearer distinction. Another example is around the word >>>>>>>>> build. When you do an app build in OpenShift it normally produces a docker >>>>>>>>> image and a running server / app. I think using the the term mobile client >>>>>>>>> build makes it clearer what is happening. >>>>>>>>> >>>>>>>>> Just a thought for a Monday morning. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Craig Brookes >>>>>>>>> RHMAP >>>>>>>>> @maleck13 Github >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> feedhenry-dev mailing list >>>>>>>>> feedhenry-dev at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Jason Madigan >>>>>>>> Engineering Manager, Red Hat Mobile >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Craig Brookes >>>>>>> RHMAP >>>>>>> @maleck13 Github >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Project lead AeroGear.org >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Project lead AeroGear.org >>>> >>>> _______________________________________________ >>>> 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 >> >> > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1deff70600823b9ebf187fa9e94df6ff10966d4e at zimbra Type: application/octet-stream Size: 11472 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ii_1605098c9cd61c41 Type: application/octet-stream Size: 70585 bytes Desc: not available URL: From matzew at apache.org Wed Dec 13 16:39:05 2017 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 13 Dec 2017 17:39:05 +0100 Subject: [feedhenry-dev] [aerogear-dev] APB service provision using secrets and configmaps and proposals in general In-Reply-To: References: Message-ID: can you record that - and share the recording ? I am traveling :-/ On Wed, Dec 13, 2017 at 2:27 PM, Craig Brookes wrote: > Great. Lets use this is a discussion point for thurday's call > > On Wed, Dec 13, 2017 at 10:48 AM, Wei Li wrote: > >> Please see my comments inline. >> >> On Wed, Dec 13, 2017 at 9:36 AM, David Martin >> wrote: >> >>> including aerogear-dev >>> >>> On 13 December 2017 at 08:55, Craig Brookes wrote: >>> >>>> Hey guys, >>>> >>>> *tldr* >>>> *- Use a combination of configmaps and secrets to store public (ie >>>> client config) vs secret (ie credentials) when provisioning services via an >>>> APB* >>>> *- Use proposals for these kind of changes (ie where they are larger >>>> changes, breaking changes or changes in technical direction that have cross >>>> cutting concerns.)* >>>> *- As we have many pieces, setup aerogear/proposals repo.* >>>> >>>> I would like to suggest that we make use of a mixture of configmap and >>>> secrets during the provision of a mobile "aware" service. >>>> Currently when we provision a service we must also create a secret with >>>> a label: mobile:enabled and at least two pieces of information: >>>> - uri >>>> - name >>>> but it often contains more (such as username and password etc) >>>> This secret is used by the UI to represent that the service is present >>>> in the namespace and to display the credential information that allows the >>>> developer to sign into the service. >>>> During the PoC this secret was also used to populate the mobile client >>>> config. This meant filtering out fields that we did not want the mobile >>>> client to have access to. >>>> My suggestion is that we move to using an additional configmap labeled >>>> "mobile:enabled" that contains the public information that can be exposed >>>> to the mobile client as configuration and a secret still labeled >>>> "mobile:enabled" to capture other information such as the credentials for >>>> logging into the service. >>>> >>>> >> +1. This is a quote I found from the author of both secret & configmap: >> >> >>> 1. Use secrets for things which are actually secret like API keys, >>> credentials, etc >>> 2. Use config map for not-secret configuration data >>> >>> So the proposed change is well aligned with this statement. >> >> >>> This really amounts to a proposal. Which brings me to the second >>>> question. Where to keep proposals? I would like us to standardise on have a >>>> public record of technical changes. These proposals should capture the >>>> following: >>>> 1) What >>>> 2) Why >>>> 3) How >>>> As an example here is a proposal that I put together for the ansible >>>> service broker: >>>> https://github.com/openshift/ansible-service-broker/blob/mas >>>> ter/docs/proposals/last-operation-description.md >>>> This shows the kind of level of detail that I believe we should be >>>> capturing. >>>> When is a proposal necessary? In my experience they are often used for >>>> larger changes, breaking changes or changes in technical direction that >>>> have cross cutting concerns. So in the case of my change outlined above, it >>>> is a breaking change that both the CLI and UI need to be aware of along >>>> with the developers of service APBs and so it should be a proposal. >>>> In the ansible service broker case the proposal is kept in the docs dir >>>> of the repo, however for something larger like Kubernetes they have a >>>> separate repo https://github.com/kubernetes/community. >>>> We could do something similar: aerogear/proposals with directories for >>>> each area >>>> - core >>>> - ui >>>> - cli >>>> - ide-extenstions >>>> - services >>>> - apbs >>>> - push >>>> - sync >>>> ... >>>> >>> >> +1 on creating a repo for the proposals. I also want to add sometimes >> there are a few options on the 'How'. In that case, it's important to list >> all the options and explain why one of them is being chosen. >> >> We probably also want to capture the status of the proposal - e.g. >> accepted, rejected, work in progress or completed etc so that community >> members can easily find out what have been done and what haven't. >> >> >>> >>>> I think this would allow the owner or gatekeeper of the proposal to be >>>> clearly identified. >>>> >>>> Interested in hearing thoughts and opinions >>>> >>>> >>>> >>>> -- >>>> Craig Brookes >>>> RHMAP >>>> @maleck13 Github >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> >> -- >> >> WEI LI >> >> SENIOR SOFTWARE ENGINEER >> >> Red Hat Mobile >> >> weil at redhat.com M: +353862393272 >> >> > > > > -- > Craig Brookes > RHMAP > @maleck13 Github > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf github: https://github.com/matzew twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrookes at redhat.com Wed Dec 13 16:47:16 2017 From: pbrookes at redhat.com (Phil Brookes) Date: Wed, 13 Dec 2017 16:47:16 +0000 Subject: [feedhenry-dev] Separate APB org or just separate repo In-Reply-To: References: Message-ID: 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 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 > wrote: > >> >> >> On Wed, Dec 13, 2017 at 3:44 PM, Phil Brookes >> 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 >>> 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 * >>>> twitter:* @johnfriz* >>>> skype: *john_frizelle* >>>> mail: *jfrizell at redhat.com * >>>> >>>> >>>> >>>> >>>> On 13 December 2017 at 14:23, David Martin 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 >>>>> 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 * >>>>>> twitter:* @johnfriz* >>>>>> skype: *john_frizelle* >>>>>> mail: *jfrizell at redhat.com * >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 13 December 2017 at 14:08, Wojciech Trocki >>>>>> 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 >>>>>>> >>>>>>> IM: wtrocki >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 > > weil at redhat.com M: +353862393272 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From mwessend at redhat.com Wed Dec 13 16:49:12 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Wed, 13 Dec 2017 17:49:12 +0100 Subject: [feedhenry-dev] Separate APB org or just separate repo In-Reply-To: References: Message-ID: 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 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 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 > > wrote: >> >>> >>> >>> On Wed, Dec 13, 2017 at 3:44 PM, Phil Brookes >>> 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 >>>> 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 * >>>>> twitter:* @johnfriz* >>>>> skype: *john_frizelle* >>>>> mail: *jfrizell at redhat.com * >>>>> >>>>> >>>>> >>>>> >>>>> On 13 December 2017 at 14:23, David Martin >>>>> 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 >>>>>> 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 * >>>>>>> twitter:* @johnfriz* >>>>>>> skype: *john_frizelle* >>>>>>> mail: *jfrizell at redhat.com * >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 13 December 2017 at 14:08, Wojciech Trocki >>>>>>> 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 >>>>>>>> >>>>>>>> IM: wtrocki >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >> >> weil at redhat.com M: +353862393272 >> >> > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From pwright at redhat.com Wed Dec 13 17:04:34 2017 From: pwright at redhat.com (Paul Wright) Date: Wed, 13 Dec 2017 17:04:34 +0000 Subject: [feedhenry-dev] mobile client or mobile app In-Reply-To: References: <4cd1277c-7043-2770-4b2c-8e1df071b49e@redhat.com> Message-ID: Ok, first, others reopened this wound, not me! But I thought it was interesting that Microsoft (of all people) have a notion of the 'inner loop' of a developer's workflow, where developers are trying to? avoid the complexity of reality, and instead create a 'Draft': Streamlining Kubernetes development with Draft Not that we're doing a similar thing, but is there a point to thinking beyond the 'construct', to the emulation/demo, while also hanging a bit to MS coattails? Paul On 12/13/2017 04:36 PM, Matthias Wessendorf wrote: > mobile app build ? > > On Wed, Dec 13, 2017 at 5:28 PM, Chris Shinn > wrote: > > That said, I do think that there?s value in ?app?. Especially > because of its ubiquity, it?s likely to be the ?search term" that > people are looking for when they are trying to find parts of the > interface that are relevant to their current task. > > > On December 13, 2017 at 10:59:54 AM, David Martin > (davmarti at redhat.com ) wrote: > >> I thought this was interesting. >> >> Chris Shinn (UX) came up with the term 'Mobile Client Build' in >> UI mockups for mobile apps on the OpenShift overview screen. >> This was to make it obvious we're talking about 'Mobile' builds >> rather than typical S2I or Docker builds. >> >> >> >> Inline images 1 >> >> On 30 November 2017 at 14:13, Matthias Wessendorf >> > wrote: >> >> I like that - and is similar to UPS terminology :) >> >> >> >> On Thu, Nov 30, 2017 at 2:23 PM, John Frizelle >> > wrote: >> >> perhaps "construct" instead of "container configuration" >> >> MobileClient: A construct that represents the overall >> mobile application on OpenShift (eg MobileHR) >> >> >> -- >> John Frizelle >> Chief Architect, Red Hat Mobile >> Consulting Engineer >> >> mobile:*+353 87 290 1644 * >> twitter:*?@johnfriz* >> skype: *john_frizelle* >> mail: *jfrizell at redhat.com * >> >> >> >> >> On 30 November 2017 at 11:48, Matthias Wessendorf >> > wrote: >> >> >> >> On Thu, Nov 30, 2017 at 12:05 PM, Paul Wright >> > wrote: >> >> last comment, then I'll stop (promise): >> >> Let's go with MobileClient, as discussed below, >> but take a bit more time about the definition. >> >> I think the definition for PushApplication is >> great in the context of UPS, but with MCP, we're >> trying to explain an item that is front and >> center, and that the user might misunderstand, or >> not act as expected. >> >> Can we be more explicit and give an example? >> >> - MobileClient: A container configuration that >> represents the overall mobile application on >> OpenShift (eg MobileHR) >> >> >> container ... hrm - not sure -? that's also >> misleading... ?! >> >> >> >> Paul >> >> >> On 11/30/2017 10:26 AM, Matthias Wessendorf wrote: >>> +1 on something like "logical construct / >>> logical representation" ?- and right UPS has >>> also had some naming struggles :) >>> >>> On Thu, Nov 30, 2017 at 11:11 AM, David Martin >>> >> > wrote: >>> >>> The term 'Resource' may not suit as it has a >>> meaning in the Kubernetes world. >>> Any object that kubernetes exposes an API >>> for is a resource e.g. Secrets, Pods, >>> Deployments are all resources. >>> >>> In UPS, there's the idea of a 'Push >>> Application', defined here [1] >>> "PushApplication >>> A logical construct that represents an >>> overall mobile application" >>> >>> I don't see any problem with giving it a >>> name like 'Mobile Client' and calling it out >>> in terminology in a similar manner >>> "MobileClient >>> A logical construct that represents an >>> overall mobile application" >>> >>> [1] >>> https://aerogear.org/docs/unifiedpush/ups_userguide/index/#_useful_terminology >>> >>> >>> On 29 November 2017 at 09:42, Paul Wright >>> >> > wrote: >>> >>> and that conversation makes me think we >>> need to be more descriptive, eg >>> >>> Mobile App Resource Client (MARC) >>> >>> Paul >>> >>> >>> On 11/29/2017 09:38 AM, Craig Brookes wrote: >>>> Spoke with Paul offline. And he thought >>>> we were referring to mobile app through >>>> out our docs. So to clarify I meant >>>> with the context of the mcp UI and CLI. >>>> >>>> On Mon, Nov 27, 2017 at 11:49 AM, Paul >>>> Wright >>> > wrote: >>>> >>>> It seems to me that to tackle the >>>> mobile market, we should embrace >>>> the lingua franca, and the one word >>>> that unites mobile,cell phone, >>>> smartphone, handys, etc is 'App' >>>> >>>> Paul >>>> >>>> my original draft reply: >>>> >>>> Mondays... >>>> >>>> Let's fix everything >>>> >>>> I'm not against this change, but >>>> would like to throw in a note of >>>> caution: >>>> >>>> 1. I don't think OpenShift are >>>> really pushing the term apps. Sure, >>>> there's a command, and even some >>>> doc references >>>> (https://access.redhat.com/documentation/en-us/openshift_enterprise/3.2/html/installation_and_configuration/install-config-imagestreams-templates#creating-instantapp-templates >>>> ), >>>> but would like to check with them >>>> before assuming that's deliberate. >>>> In my mind, their term of choice is >>>> Application, a bit more of an >>>> enterprisey term. >>>> >>>> 2. Does "Mobile Clients" solve a >>>> problem? we already have a >>>> generation of ppl saying "there's >>>> an app for that", do we want to >>>> embrace that or swim upstream? what >>>> about when there's a web ui to >>>> something, we used to bundle mobile >>>> and web into the term 'client app'. >>>> >>>> >>>> >>>> >>>> >>>> On 11/27/2017 11:03 AM, Jason >>>> Madigan wrote: >>>>> Deep thoughts this early in the >>>>> week. App is quite a loaded term >>>>> alright, particularly in an >>>>> OpenShift context, so I think >>>>> Mobile Client may be a clearer >>>>> distinction. >>>>> >>>>> Looping in our wordsmith Paul who >>>>> may have other ideas. >>>>> >>>>> On Mon, Nov 27, 2017 at 9:44 AM, >>>>> Craig Brookes >>>> > wrote: >>>>> >>>>> Was thinking about terminology >>>>> . We have been using the term >>>>> mobile app, but I wonder would >>>>> it be clearer to use the term >>>>> mobile client instead. >>>>> The main reason for this is >>>>> that app can mean a server >>>>> side component (in OpenShift >>>>> there is the new-app command >>>>> for example). I think it would >>>>> make a clearer distinction. >>>>> Another example is around the >>>>> word build. When you do an app >>>>> build in OpenShift it normally >>>>> produces a docker image and a >>>>> running server / app. I think >>>>> using the the term mobile >>>>> client build makes it clearer >>>>> what is happening. >>>>> >>>>> Just a thought for a Monday >>>>> morning. >>>>> >>>>> -- >>>>> Craig Brookes >>>>> RHMAP >>>>> @maleck13 Github >>>>> >>>>> _______________________________________________ >>>>> feedhenry-dev mailing list >>>>> feedhenry-dev at redhat.com >>>>> >>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Jason Madigan >>>>> Engineering Manager, Red Hat Mobile >>>> >>>> >>>> >>>> >>>> -- >>>> Craig Brookes >>>> RHMAP >>>> @maleck13 Github >>> >>> >>> _______________________________________________ >>> 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 >>> >>> >>> >>> >>> >>> -- >>> Project lead AeroGear.org >> >> >> >> >> -- >> Project lead AeroGear.org >> >> _______________________________________________ >> 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 >> >> >> >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (feedhenry, mobile-internal) > > > > > -- > Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From weil at redhat.com Wed Dec 13 17:14:11 2017 From: weil at redhat.com (Wei Li) Date: Wed, 13 Dec 2017 17:14:11 +0000 Subject: [feedhenry-dev] Separate APB org or just separate repo In-Reply-To: References: Message-ID: > > 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 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 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 wrote: >> >>> I am in favour of separate repo for each item as well. However, I am not >>> convinced about separate APB org, or why there is only an org for APBs, >>> what about client SDKs, or services? Should we create orgs for them as >>> well? If not, why APBs are treated differently? >>> >>> I think it's ok to have everything in one org, but I think we should >>> have a website that clearly describe how things are organised. I would >>> image we will have a dedicated page for each service, and from there >>> developers/community members can find everything they need about a service. >>> >>> >>> >>> On Wed, Dec 13, 2017 at 2:54 PM, Matthias Wessendorf < >>> mwessend at redhat.com> wrote: >>> >>>> >>>> >>>> On Wed, Dec 13, 2017 at 3:44 PM, Phil Brookes >>>> 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 >>>>> 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 * >>>>>> twitter:* @johnfriz* >>>>>> skype: *john_frizelle* >>>>>> mail: *jfrizell at redhat.com * >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 13 December 2017 at 14:23, David Martin >>>>>> 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 >>>>>>> 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 * >>>>>>>> twitter:* @johnfriz* >>>>>>>> skype: *john_frizelle* >>>>>>>> mail: *jfrizell at redhat.com * >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 13 December 2017 at 14:08, Wojciech Trocki >>>>>>>> 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 >>>>>>>>> >>>>>>>>> IM: wtrocki >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>> >>> weil at redhat.com M: +353862393272 >>> >>> >> >> > > > -- > Project lead AeroGear.org > -- WEI LI SENIOR SOFTWARE ENGINEER Red Hat Mobile weil at redhat.com M: +353862393272 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From wtrocki at redhat.com Wed Dec 13 19:20:05 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Wed, 13 Dec 2017 19:20:05 +0000 Subject: [feedhenry-dev] Separate APB org or just separate repo In-Reply-To: References: Message-ID: 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: https://github.com/firebase/firebase-js-sdk/pull/171 They using proven tool: lerna to manage all npm packages. On Wed, Dec 13, 2017 at 2:29 PM, John Frizelle 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 * > twitter:* @johnfriz* > skype: *john_frizelle* > mail: *jfrizell at redhat.com * > > > > > On 13 December 2017 at 14:23, David Martin 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 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 * >>> twitter:* @johnfriz* >>> skype: *john_frizelle* >>> mail: *jfrizell at redhat.com * >>> >>> >>> >>> >>> On 13 December 2017 at 14:08, Wojciech Trocki >>> wrote: >>> >>>> >>>> >>>> On Wed, Dec 13, 2017 at 1:55 PM, Summers Pittman >>>> 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 >>>>>> 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 >>>> >>>> IM: wtrocki >>>> >>>> >>>> _______________________________________________ >>>> 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) >> > > -- WOJCIECH TROCKI Red Hat Mobile IM: wtrocki -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From supittma at redhat.com Thu Dec 14 14:22:31 2017 From: supittma at redhat.com (Summers Pittman) Date: Thu, 14 Dec 2017 09:22:31 -0500 Subject: [feedhenry-dev] Android MCP SDK Goals Doc Message-ID: A few weeks ago we kicked off some discussions on the Android SDK. Since we've had a lot of things happen since then I am recirculating the doc and rekickstarting the conversation. Cross posting with feedhenry-dev because the aerogear-dev list seems to be being a bit ill. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lgriffin at redhat.com Thu Dec 14 14:56:44 2017 From: lgriffin at redhat.com (Leigh Griffin) Date: Thu, 14 Dec 2017 14:56:44 +0000 Subject: [feedhenry-dev] Android MCP SDK Goals Doc In-Reply-To: References: Message-ID: Got a link? On Thu, Dec 14, 2017 at 2:22 PM, Summers Pittman wrote: > A few weeks ago we kicked off some discussions on the Android SDK. Since > we've had a lot of things happen since then I am recirculating the doc and > rekickstarting the conversation. > > Cross posting with feedhenry-dev because the aerogear-dev list seems to be > being a bit ill. > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- LEIGH GRIFFIN ENGINEERING MANAGER, MOBILE Red Hat Ireland Communications House, Cork Road Waterford City, Ireland X91NY33 lgriffin at redhat.com M: +353877545162 IM: lgriffin TRIED. TESTED. TRUSTED. @redhatway @redhatinc @redhatsnaps -------------- next part -------------- An HTML attachment was scrubbed... URL: From supittma at redhat.com Thu Dec 14 14:58:48 2017 From: supittma at redhat.com (Summers Pittman) Date: Thu, 14 Dec 2017 09:58:48 -0500 Subject: [feedhenry-dev] Android MCP SDK Goals Doc In-Reply-To: References: Message-ID: https://docs.google.com/document/d/1b_X8wTG9yqAbBzhpK-P9DifCrTWXgdBBOiN7fO3qsgM/edit# Sorry about that, here's the link. I'll be migrating the doc to github.com/aerogear/proposals this afernoon. On Thu, Dec 14, 2017 at 9:56 AM, Leigh Griffin wrote: > Got a link? > > On Thu, Dec 14, 2017 at 2:22 PM, Summers Pittman > wrote: > >> A few weeks ago we kicked off some discussions on the Android SDK. Since >> we've had a lot of things happen since then I am recirculating the doc and >> rekickstarting the conversation. >> >> Cross posting with feedhenry-dev because the aerogear-dev list seems to >> be being a bit ill. >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > > LEIGH GRIFFIN > > ENGINEERING MANAGER, MOBILE > > Red Hat Ireland > > Communications House, Cork Road > > Waterford City, Ireland X91NY33 > > lgriffin at redhat.com M: +353877545162 IM: lgriffin > > TRIED. TESTED. TRUSTED. > > @redhatway @redhatinc > @redhatsnaps > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Thu Dec 14 15:51:40 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Thu, 14 Dec 2017 16:51:40 +0100 Subject: [feedhenry-dev] AeroGear attic ogranization ? In-Reply-To: References: Message-ID: Hi, I've created the 'attic': https://github.com/aerogear-attic the two suggested repos are now in there I will compile a list w/ more details (e.g. list of all vs. list of what to _potentially_) keep -M On Wed, Dec 13, 2017 at 2:52 PM, Matthias Wessendorf wrote: > Hi, > > we are in the process of cleaning up old repos. In order to avoid a > deletion - now - I think it would be good to move them into some special GH > org. > > I propose the usage of "aerogear-attic" of all repos that have come to > their end of life. we can park the there, and see how things evolve - and > perhaps, eventually we will be deleting them, from there. > > Any thoughts? > > > Two repos that are already now "archived" (aka read-only) are: > * https://github.com/aerogear/aerogear-android-offline > * https://github.com/aerogear/aerogear-android > > > Thoughts? Should we move these ? > > Besides that, here are two relevant threads from passos on some other > 'eol' repos: > * http://lists.jboss.org/pipermail/aerogear-dev/2017-October/013078.html > * http://lists.jboss.org/pipermail/aerogear-dev/2017-October/013079.html > (already covered above) > > Thoughts? Moving the sync stuff over the attic ? > > -Matthias > > -- > Project lead AeroGear.org > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From supittma at redhat.com Thu Dec 14 16:14:51 2017 From: supittma at redhat.com (Summers Pittman) Date: Thu, 14 Dec 2017 11:14:51 -0500 Subject: [feedhenry-dev] Android MCP SDK Goals Doc In-Reply-To: References: Message-ID: After chatting with some of the guys, I've moved this document to the aerogear/proposals repository. Please continue/port any discussions to the PR here : https://github.com/aerogear/proposals/pull/2 On Thu, Dec 14, 2017 at 9:58 AM, Summers Pittman wrote: > https://docs.google.com/document/d/1b_X8wTG9yqAbBzhpK- > P9DifCrTWXgdBBOiN7fO3qsgM/edit# > > Sorry about that, here's the link. I'll be migrating the doc to > github.com/aerogear/proposals this afernoon. > > On Thu, Dec 14, 2017 at 9:56 AM, Leigh Griffin > wrote: > >> Got a link? >> >> On Thu, Dec 14, 2017 at 2:22 PM, Summers Pittman >> wrote: >> >>> A few weeks ago we kicked off some discussions on the Android SDK. >>> Since we've had a lot of things happen since then I am recirculating the >>> doc and rekickstarting the conversation. >>> >>> Cross posting with feedhenry-dev because the aerogear-dev list seems to >>> be being a bit ill. >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> >> LEIGH GRIFFIN >> >> ENGINEERING MANAGER, MOBILE >> >> Red Hat Ireland >> >> Communications House, Cork Road >> >> Waterford City, Ireland X91NY33 >> >> lgriffin at redhat.com M: +353877545162 IM: lgriffin >> >> TRIED. TESTED. TRUSTED. >> >> @redhatway @redhatinc >> @redhatsnaps >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cbrookes at redhat.com Fri Dec 15 10:05:46 2017 From: cbrookes at redhat.com (Craig Brookes) Date: Fri, 15 Dec 2017 10:05:46 +0000 Subject: [feedhenry-dev] When to merge a proposal Message-ID: I think we should use a common strategy in the Open Source world, that in general you need at least two LGTM thumbs up from bona fide reviewers before being allowed to merge. Thoughts? -- Craig Brookes RHMAP @maleck13 Github -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfrizell at redhat.com Fri Dec 15 10:06:32 2017 From: jfrizell at redhat.com (John Frizelle) Date: Fri, 15 Dec 2017 10:06:32 +0000 Subject: [feedhenry-dev] When to merge a proposal In-Reply-To: References: Message-ID: LGTM :-) -- John Frizelle Chief Architect, Red Hat Mobile Consulting Engineer mobile: *+353 87 290 1644 * twitter:* @johnfriz* skype: *john_frizelle* mail: *jfrizell at redhat.com * On 15 December 2017 at 10:05, Craig Brookes wrote: > I think we should use a common strategy in the Open Source world, that in > general you need at least two LGTM thumbs up from bona fide reviewers > before being allowed to merge. > > Thoughts? > > -- > Craig Brookes > RHMAP > @maleck13 Github > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From davmarti at redhat.com Fri Dec 15 10:14:38 2017 From: davmarti at redhat.com (David Martin) Date: Fri, 15 Dec 2017 10:14:38 +0000 Subject: [feedhenry-dev] When to merge a proposal In-Reply-To: References: Message-ID: +1 On 15 December 2017 at 10:06, John Frizelle wrote: > LGTM :-) > > -- > John Frizelle > Chief Architect, Red Hat Mobile > Consulting Engineer > > mobile: *+353 87 290 1644 * > twitter:* @johnfriz* > skype: *john_frizelle* > mail: *jfrizell at redhat.com * > > > > > On 15 December 2017 at 10:05, Craig Brookes wrote: > >> I think we should use a common strategy in the Open Source world, that in >> general you need at least two LGTM thumbs up from bona fide reviewers >> before being allowed to merge. >> >> Thoughts? >> >> -- >> Craig Brookes >> RHMAP >> @maleck13 Github >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From davmarti at redhat.com Fri Dec 15 11:15:38 2017 From: davmarti at redhat.com (David Martin) Date: Fri, 15 Dec 2017 11:15:38 +0000 Subject: [feedhenry-dev] 5.x Local Development Message-ID: Thoughts on doing this welcome TLDR * Move the mcp-standalone repo to Aerogear github org * remove the mcp server * remove the mcp-standalone service from the Android, iOS & Cordova APBs * remove the Mobile Tab from the UI * use the remaining ansible stuff for local development Goals of a 5.x local development environment * environment for developing services * a running OpenShift for developing the CLI against * ability to develop the OpenShift UI with a quick feedback loop * has the Service Catalog & OpenShift Ansible Broker (for developing APBs) DETAILS Move the mcp-standalone repo to Aerogear github org * part of the overall shift to the aerogear community, and drawing a line under the 5.x POC work Remove the mcp server * the mcp server is not going to be continued * it was providing some smarts around openshift, which will ultimately live in APBs or the CLI/UI Remove the mcp-standalone service from the Android, iOS & Cordova APBs * See last point as the server is not required * these App APBs will just need to create a mobile app representation in OpenShift e.g. a ConfigMap or Mobile App CRD [1] (Separate proposal/discussion for switching to a CRD) Remove the Mobile Tab from the UI * Working with UX people, the Mobile tab is not the route we're taking * Mobile will become more relevant on the main OpenShift Overview page * UI development can continue similar to before (via UI extensions) until a decision is made about how mobile bits make it into the Openshift Web Console Use the remaining ansible stuff for local development * The ansible playbooks & roles in this repo are very useful for setting up openshift with the ansible service broker [1] https://kubernetes.io/docs/concepts/api-extension/custom-resources/ -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Fri Dec 15 11:32:07 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Fri, 15 Dec 2017 12:32:07 +0100 Subject: [feedhenry-dev] 5.x Local Development In-Reply-To: References: Message-ID: +1 on all of that On Fri, Dec 15, 2017 at 12:15 PM, David Martin wrote: > Thoughts on doing this welcome > > TLDR > * Move the mcp-standalone repo to Aerogear github org > * remove the mcp server > * remove the mcp-standalone service from the Android, iOS & Cordova APBs > * remove the Mobile Tab from the UI > * use the remaining ansible stuff for local development > > > Goals of a 5.x local development environment > * environment for developing services > * a running OpenShift for developing the CLI against > * ability to develop the OpenShift UI with a quick feedback loop > * has the Service Catalog & OpenShift Ansible Broker (for developing APBs) > > > DETAILS > Move the mcp-standalone repo to Aerogear github org > * part of the overall shift to the aerogear community, and drawing a line > under the 5.x POC work > > Remove the mcp server > * the mcp server is not going to be continued > * it was providing some smarts around openshift, which will ultimately > live in APBs or the CLI/UI > > Remove the mcp-standalone service from the Android, iOS & Cordova APBs > * See last point as the server is not required > * these App APBs will just need to create a mobile app representation in > OpenShift e.g. a ConfigMap or Mobile App CRD [1] (Separate > proposal/discussion for switching to a CRD) > > Remove the Mobile Tab from the UI > * Working with UX people, the Mobile tab is not the route we're taking > * Mobile will become more relevant on the main OpenShift Overview page > * UI development can continue similar to before (via UI extensions) until > a decision is made about how mobile bits make it into the Openshift Web > Console > > Use the remaining ansible stuff for local development > * The ansible playbooks & roles in this repo are very useful for setting > up openshift with the ansible service broker > > > [1] https://kubernetes.io/docs/concepts/api-extension/custom-resources/ > -- > 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 > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Fri Dec 15 11:34:26 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Fri, 15 Dec 2017 11:34:26 +0000 Subject: [feedhenry-dev] 5.x Local Development In-Reply-To: References: Message-ID: +1 * remove the mcp server > Can we move that to new attic organization to have future reference if needed? -- WOJCIECH TROCKI Red Hat Mobile IM: wtrocki -------------- next part -------------- An HTML attachment was scrubbed... URL: From jfrizell at redhat.com Fri Dec 15 11:35:18 2017 From: jfrizell at redhat.com (John Frizelle) Date: Fri, 15 Dec 2017 11:35:18 +0000 Subject: [feedhenry-dev] 5.x Local Development In-Reply-To: References: Message-ID: I wonder about renaming mcp-standalone as part of the move - perhaps to "mobile-core" or similar. -- John Frizelle Chief Architect, Red Hat Mobile Consulting Engineer mobile: *+353 87 290 1644 * twitter:* @johnfriz* skype: *john_frizelle* mail: *jfrizell at redhat.com * On 15 December 2017 at 11:32, Matthias Wessendorf wrote: > +1 on all of that > > On Fri, Dec 15, 2017 at 12:15 PM, David Martin > wrote: > >> Thoughts on doing this welcome >> >> TLDR >> * Move the mcp-standalone repo to Aerogear github org >> * remove the mcp server >> * remove the mcp-standalone service from the Android, iOS & Cordova APBs >> * remove the Mobile Tab from the UI >> * use the remaining ansible stuff for local development >> >> >> Goals of a 5.x local development environment >> * environment for developing services >> * a running OpenShift for developing the CLI against >> * ability to develop the OpenShift UI with a quick feedback loop >> * has the Service Catalog & OpenShift Ansible Broker (for developing APBs) >> >> >> DETAILS >> Move the mcp-standalone repo to Aerogear github org >> * part of the overall shift to the aerogear community, and drawing a line >> under the 5.x POC work >> >> Remove the mcp server >> * the mcp server is not going to be continued >> * it was providing some smarts around openshift, which will ultimately >> live in APBs or the CLI/UI >> >> Remove the mcp-standalone service from the Android, iOS & Cordova APBs >> * See last point as the server is not required >> * these App APBs will just need to create a mobile app representation in >> OpenShift e.g. a ConfigMap or Mobile App CRD [1] (Separate >> proposal/discussion for switching to a CRD) >> >> Remove the Mobile Tab from the UI >> * Working with UX people, the Mobile tab is not the route we're taking >> * Mobile will become more relevant on the main OpenShift Overview page >> * UI development can continue similar to before (via UI extensions) until >> a decision is made about how mobile bits make it into the Openshift Web >> Console >> >> Use the remaining ansible stuff for local development >> * The ansible playbooks & roles in this repo are very useful for setting >> up openshift with the ansible service broker >> >> >> [1] https://kubernetes.io/docs/concepts/api-extension/custom-resources/ >> -- >> 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 >> >> > > > -- > Project lead AeroGear.org > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From davmarti at redhat.com Fri Dec 15 13:04:44 2017 From: davmarti at redhat.com (David Martin) Date: Fri, 15 Dec 2017 13:04:44 +0000 Subject: [feedhenry-dev] 5.x Local Development In-Reply-To: References: Message-ID: Renaming sounds good to me. So initially, this repo would have: - APBs for Mobile Apps - Ansible playbooks for bringing up local openshift cluster with service-catalog & ansible broker - UI code for Mobile bits in the OpenShift Web Console i'm good with mobile-core as it's a good starting point for developers On 15 December 2017 at 11:35, John Frizelle wrote: > I wonder about renaming mcp-standalone as part of the move - perhaps to > "mobile-core" or similar. > > -- > John Frizelle > Chief Architect, Red Hat Mobile > Consulting Engineer > > mobile: *+353 87 290 1644 * > twitter:* @johnfriz* > skype: *john_frizelle* > mail: *jfrizell at redhat.com * > > > > > On 15 December 2017 at 11:32, Matthias Wessendorf > wrote: > >> +1 on all of that >> >> On Fri, Dec 15, 2017 at 12:15 PM, David Martin >> wrote: >> >>> Thoughts on doing this welcome >>> >>> TLDR >>> * Move the mcp-standalone repo to Aerogear github org >>> * remove the mcp server >>> * remove the mcp-standalone service from the Android, iOS & Cordova APBs >>> * remove the Mobile Tab from the UI >>> * use the remaining ansible stuff for local development >>> >>> >>> Goals of a 5.x local development environment >>> * environment for developing services >>> * a running OpenShift for developing the CLI against >>> * ability to develop the OpenShift UI with a quick feedback loop >>> * has the Service Catalog & OpenShift Ansible Broker (for developing >>> APBs) >>> >>> >>> DETAILS >>> Move the mcp-standalone repo to Aerogear github org >>> * part of the overall shift to the aerogear community, and drawing a >>> line under the 5.x POC work >>> >>> Remove the mcp server >>> * the mcp server is not going to be continued >>> * it was providing some smarts around openshift, which will ultimately >>> live in APBs or the CLI/UI >>> >>> Remove the mcp-standalone service from the Android, iOS & Cordova APBs >>> * See last point as the server is not required >>> * these App APBs will just need to create a mobile app representation in >>> OpenShift e.g. a ConfigMap or Mobile App CRD [1] (Separate >>> proposal/discussion for switching to a CRD) >>> >>> Remove the Mobile Tab from the UI >>> * Working with UX people, the Mobile tab is not the route we're taking >>> * Mobile will become more relevant on the main OpenShift Overview page >>> * UI development can continue similar to before (via UI extensions) >>> until a decision is made about how mobile bits make it into the Openshift >>> Web Console >>> >>> Use the remaining ansible stuff for local development >>> * The ansible playbooks & roles in this repo are very useful for setting >>> up openshift with the ansible service broker >>> >>> >>> [1] https://kubernetes.io/docs/concepts/api-extension/custom-resources/ >>> -- >>> 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 >>> >>> >> >> >> -- >> Project lead AeroGear.org >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From matzew at apache.org Fri Dec 15 13:27:07 2017 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 15 Dec 2017 14:27:07 +0100 Subject: [feedhenry-dev] [aerogear-dev] 5.x Local Development In-Reply-To: References: Message-ID: On Fri 15. Dec 2017 at 12:54, Wojciech Trocki wrote: > +1 > > * remove the mcp server >> > > Can we move that to new attic organization to have future reference if > needed? > for me the attic is really for old AeroGear stuff How about we fork 'mcp-standalone' into aerogear, and work on it there - while keeping the original repo (archived / read-only) in feedhenry ? > > -- > > WOJCIECH TROCKI > > Red Hat Mobile > > IM: wtrocki > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From lfitzger at redhat.com Fri Dec 15 13:56:57 2017 From: lfitzger at redhat.com (Laura Fitzgerald) Date: Fri, 15 Dec 2017 13:56:57 +0000 Subject: [feedhenry-dev] Suggestion/Discussion - Removal of AeroGear.org Production Branch In-Reply-To: References: Message-ID: Hi all, I had sent this email re improving the way that we pubish aerogear.org. Some may have seen it and replied but as there is some problems with aerogear-dev mailing and there has been some further discussions I wanted to reopen a conversation re Aerogear.org. With the move to the aerogear org there has been some conversation aroung an overhaul of the aerogear.org website. It was also suggested that we could go with a brand new site rather than rejigging the old site. I'm thinking that it would be worth having a discussion around how we would go about this. If anyone has particular interest in this and/or experience with the old site and existing tech and wants to open a proposal/discussion re tech stack, design, content etc I think it would be suitable to to do that via the proposals repo [1] or via some discussion here. I've been involved in adding some content recently with the Aerogear Digger Project and my vote would be for creating something new and shiny!!! Wdy guys t? [1] https://github.com/aerogear/proposals On Wed, Dec 6, 2017 at 11:07 AM, Laura Fitzgerald wrote: > Hi all, > > I have recently gone through the process of publishing documentation for > AeroGear Digger to aerogear.org. > > The process for adding docs for digger was as follows: > > - Make changes on Feature Branch over a period of time. > - At some point merge lots of commits (difficult to review) from Feature > Branch to master. > - This publishes to staging.aerogear.org (build needs to be manually > triggered in Jenkins) > - At some point merge master (again with lots of commits) to production > branch > - This publishes to aerogear.org (build needs to be manually triggered) > > Out of this we attempted to improve the process by adding development > steps to the README [1] outlining that > -> each change should be verified on it's own -> merged to master -> and > then merged to production > removing the wait time and merges which involved lots of commits and > changes. > > *I think there are a few things we can do to make this better. (simpler)* > > *1) How?* > > Remove the production branch (and related steps) altogether. > > *Why?* > > - All this documentation is done in the open. > - All branches are visible to all users/developers. > - staging.aerogear.org is not private so I don't see that we gain > something by having this step. > - Changes can be verified locally by building the website using the steps > in the README [2] before being merged to master. > > *2) How?* > Automate the publishing of the site > > *Why?* > Right now the building of the site has to be triggered manually via a > Jenkins instance on cloudbees. If we remove production and enforce that all > changes are fully verified before being merged to master then we can > automate that any new changes are published immediately once merged to > master. > > *3) How?* > Add some sort of versioning to the documentation. This could be in the > form of tagging the repo once we have a release of a product. > > *Why?* > If we are always publishing docs once a change is made to the product then > we should version the documentation so we know which version of the docs > matches older versions of the product. > > ~~~~~~~~~~~ > > I'm really interested in some feedback on this. Let me know what you > think. Is there a better/simpler way to do it than I suggested? > > [1] https://github.com/aerogear/aerogear.org/blob/ > master/README.md#development-steps > [2] https://github.com/aerogear/aerogear.org/blob/ > master/README.md#building > -- > > LAURA FITZGERALD > > Red Hat Mobile > > Communications House, Cork Road > > Waterford City, Ireland X91NY33 > > lfitzger at redhat.com IM: lfitzgerald > > > -- LAURA FITZGERALD Red Hat Mobile Communications House, Cork Road Waterford City, Ireland X91NY33 lfitzger at redhat.com IM: lfitzgerald -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Fri Dec 15 14:01:31 2017 From: davmarti at redhat.com (David Martin) Date: Fri, 15 Dec 2017 14:01:31 +0000 Subject: [feedhenry-dev] [aerogear-dev] 5.x Local Development In-Reply-To: References: Message-ID: Fork & archive sounds good to me. I'll plan to progress these changes on Monday, with a name of 'mobile-core' for the new repo, unless further discussions happen before then On 15 December 2017 at 13:27, Matthias Wessendorf wrote: > > > On Fri 15. Dec 2017 at 12:54, Wojciech Trocki wrote: > >> +1 >> >> * remove the mcp server >>> >> >> Can we move that to new attic organization to have future reference if >> needed? >> > > for me the attic is really for old AeroGear stuff > > How about we fork 'mcp-standalone' into aerogear, and work on it there - > while keeping the original repo (archived / read-only) in feedhenry ? > > >> >> -- >> >> WOJCIECH TROCKI >> >> Red Hat Mobile >> >> IM: wtrocki >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Fri Dec 15 16:04:49 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Fri, 15 Dec 2017 17:04:49 +0100 Subject: [feedhenry-dev] APB relocation ... Message-ID: Hi, as discussed on IRC, I've forked the APBs to aerogearcatalog organization, and have 'archived' (aka read-only) the feedhenry matching repos: * https://github.com/feedhenry/keycloak-apb * https://github.com/feedhenry/prometheus-apb * https://github.com/feedhenry/aerogear-digger-apb * https://github.com/feedhenry/fh-sync-server-apb * https://github.com/feedhenry/3scale-apb * https://github.com/feedhenry/unifiedpush-apb You find them now in: https://github.com/aerogearcatalog I've also enabled the hub for automatic builds: https://hub.docker.com/r/aerogearcatalog/ and a matching PR for the "MCP": https://github.com/feedhenry/mcp-standalone/pull/245/files Question (well, RECOMMENDATION): Are you OK I am DELETING the "feedhenry/blah-apb" repos, on the docker-hub? Ansible recently did the same... when they renamed "apb" to "apb-tools" - to avoid downloads from "old" stuff - I'd strongly recommend deleting the 'old' stuff, on the hub :) Cheers! Matthias -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Fri Dec 15 16:08:38 2017 From: davmarti at redhat.com (David Martin) Date: Fri, 15 Dec 2017 16:08:38 +0000 Subject: [feedhenry-dev] APB relocation ... In-Reply-To: References: Message-ID: +1 on deleting the image repos on docker hub For anyone not up to date on mcp-standalone then, the catalog will not show any of the mobile apbs. Worth sending a follow up after they are deleted On 15 December 2017 at 16:04, Matthias Wessendorf wrote: > Hi, > > as discussed on IRC, I've forked the APBs to aerogearcatalog organization, > and have 'archived' (aka read-only) the feedhenry matching repos: > > * https://github.com/feedhenry/keycloak-apb > * https://github.com/feedhenry/prometheus-apb > * https://github.com/feedhenry/aerogear-digger-apb > * https://github.com/feedhenry/fh-sync-server-apb > * https://github.com/feedhenry/3scale-apb > * https://github.com/feedhenry/unifiedpush-apb > > You find them now in: > https://github.com/aerogearcatalog > > I've also enabled the hub for automatic builds: > https://hub.docker.com/r/aerogearcatalog/ > > and a matching PR for the "MCP": > https://github.com/feedhenry/mcp-standalone/pull/245/files > > > Question (well, RECOMMENDATION): > Are you OK I am DELETING the "feedhenry/blah-apb" repos, on the > docker-hub? > > Ansible recently did the same... when they renamed "apb" to "apb-tools" - > to avoid downloads from "old" stuff - I'd strongly recommend deleting the > 'old' stuff, on the hub :) > > Cheers! > Matthias > > > > -- > Project lead AeroGear.org > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Fri Dec 15 16:15:53 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Fri, 15 Dec 2017 17:15:53 +0100 Subject: [feedhenry-dev] APB relocation ... In-Reply-To: References: Message-ID: On Fri, Dec 15, 2017 at 5:08 PM, David Martin wrote: > +1 on deleting the image repos on docker hub > For anyone not up to date on mcp-standalone then, the catalog will not > show any of the mobile apbs. > Worth sending a follow up after they are deleted > yeah, a note - with drums and fire :) will be sent out > > On 15 December 2017 at 16:04, Matthias Wessendorf > wrote: > >> Hi, >> >> as discussed on IRC, I've forked the APBs to aerogearcatalog >> organization, and have 'archived' (aka read-only) the feedhenry matching >> repos: >> >> * https://github.com/feedhenry/keycloak-apb >> * https://github.com/feedhenry/prometheus-apb >> * https://github.com/feedhenry/aerogear-digger-apb >> * https://github.com/feedhenry/fh-sync-server-apb >> * https://github.com/feedhenry/3scale-apb >> * https://github.com/feedhenry/unifiedpush-apb >> >> You find them now in: >> https://github.com/aerogearcatalog >> >> I've also enabled the hub for automatic builds: >> https://hub.docker.com/r/aerogearcatalog/ >> >> and a matching PR for the "MCP": >> https://github.com/feedhenry/mcp-standalone/pull/245/files >> >> >> Question (well, RECOMMENDATION): >> Are you OK I am DELETING the "feedhenry/blah-apb" repos, on the >> docker-hub? >> >> Ansible recently did the same... when they renamed "apb" to "apb-tools" - >> to avoid downloads from "old" stuff - I'd strongly recommend deleting the >> 'old' stuff, on the hub :) >> >> Cheers! >> Matthias >> >> >> >> -- >> Project lead AeroGear.org >> >> _______________________________________________ >> 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) > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Fri Dec 15 17:11:27 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Fri, 15 Dec 2017 18:11:27 +0100 Subject: [feedhenry-dev] DELETED OLD IMAGES (was: Re: APB relocation ...) Message-ID: Hi, our ASB is now pointing to the new dockerhub org, and builds for our six service are already there. TODO: go and update your branch of 'mcp', and re-run the installer: that will get images from the "aerogearcatalog" org. In addition, I've - on Docker-Hub, deleted these six repos: * feedhenry/keycloak-apb * feedhenry/3scale-apb * feedhenry/fh-sync-server-apb * feedhenry/aerogear-digger-apb * feedhenry/unifiedpush-apb * feedhenry/prometheus-apb greetings, Matthias On Fri, Dec 15, 2017 at 5:15 PM, Matthias Wessendorf wrote: > > > On Fri, Dec 15, 2017 at 5:08 PM, David Martin wrote: > >> +1 on deleting the image repos on docker hub >> For anyone not up to date on mcp-standalone then, the catalog will not >> show any of the mobile apbs. >> Worth sending a follow up after they are deleted >> > > yeah, a note - with drums and fire :) will be sent out > > >> >> On 15 December 2017 at 16:04, Matthias Wessendorf >> wrote: >> >>> Hi, >>> >>> as discussed on IRC, I've forked the APBs to aerogearcatalog >>> organization, and have 'archived' (aka read-only) the feedhenry matching >>> repos: >>> >>> * https://github.com/feedhenry/keycloak-apb >>> * https://github.com/feedhenry/prometheus-apb >>> * https://github.com/feedhenry/aerogear-digger-apb >>> * https://github.com/feedhenry/fh-sync-server-apb >>> * https://github.com/feedhenry/3scale-apb >>> * https://github.com/feedhenry/unifiedpush-apb >>> >>> You find them now in: >>> https://github.com/aerogearcatalog >>> >>> I've also enabled the hub for automatic builds: >>> https://hub.docker.com/r/aerogearcatalog/ >>> >>> and a matching PR for the "MCP": >>> https://github.com/feedhenry/mcp-standalone/pull/245/files >>> >>> >>> Question (well, RECOMMENDATION): >>> Are you OK I am DELETING the "feedhenry/blah-apb" repos, on the >>> docker-hub? >>> >>> Ansible recently did the same... when they renamed "apb" to "apb-tools" >>> - to avoid downloads from "old" stuff - I'd strongly recommend deleting the >>> 'old' stuff, on the hub :) >>> >>> Cheers! >>> Matthias >>> >>> >>> >>> -- >>> Project lead AeroGear.org >>> >>> _______________________________________________ >>> 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) >> > > > > -- > Project lead AeroGear.org > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Mon Dec 18 09:30:49 2017 From: davmarti at redhat.com (David Martin) Date: Mon, 18 Dec 2017 09:30:49 +0000 Subject: [feedhenry-dev] [aerogear-dev] 5.x Local Development In-Reply-To: References: Message-ID: Making these changes this today. I'll send out another mail with any instructions required once complete. On 15 December 2017 at 14:01, David Martin wrote: > Fork & archive sounds good to me. > > I'll plan to progress these changes on Monday, with a name of > 'mobile-core' for the new repo, unless further discussions happen before > then > > On 15 December 2017 at 13:27, Matthias Wessendorf > wrote: > >> >> >> On Fri 15. Dec 2017 at 12:54, Wojciech Trocki wrote: >> >>> +1 >>> >>> * remove the mcp server >>>> >>> >>> Can we move that to new attic organization to have future reference if >>> needed? >>> >> >> for me the attic is really for old AeroGear stuff >> >> How about we fork 'mcp-standalone' into aerogear, and work on it there - >> while keeping the original repo (archived / read-only) in feedhenry ? >> >> >>> >>> -- >>> >>> WOJCIECH TROCKI >>> >>> Red Hat Mobile >>> >>> IM: wtrocki >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Mon Dec 18 11:23:57 2017 From: davmarti at redhat.com (David Martin) Date: Mon, 18 Dec 2017 11:23:57 +0000 Subject: [feedhenry-dev] [aerogear-dev] 5.x Local Development In-Reply-To: References: Message-ID: Regarding this step, * remove the mcp-standalone service from the Android, iOS & Cordova APBs I'll be moving the App APBs to their own individual repos in the aerogearcatalog github org. Reasons: * All other APBs are in the aerogearcatalog org now * The 3 App APBs were responsible for provisioning the mcp-standalone server. There is no longer a mcp-standalone server, so the need to have them in the same repo as that server has gone. On 18 December 2017 at 09:30, David Martin wrote: > Making these changes this today. > I'll send out another mail with any instructions required once complete. > > On 15 December 2017 at 14:01, David Martin wrote: > >> Fork & archive sounds good to me. >> >> I'll plan to progress these changes on Monday, with a name of >> 'mobile-core' for the new repo, unless further discussions happen before >> then >> >> On 15 December 2017 at 13:27, Matthias Wessendorf >> wrote: >> >>> >>> >>> On Fri 15. Dec 2017 at 12:54, Wojciech Trocki >>> wrote: >>> >>>> +1 >>>> >>>> * remove the mcp server >>>>> >>>> >>>> Can we move that to new attic organization to have future reference if >>>> needed? >>>> >>> >>> for me the attic is really for old AeroGear stuff >>> >>> How about we fork 'mcp-standalone' into aerogear, and work on it there - >>> while keeping the original repo (archived / read-only) in feedhenry ? >>> >>> >>>> >>>> -- >>>> >>>> WOJCIECH TROCKI >>>> >>>> Red Hat Mobile >>>> >>>> IM: wtrocki >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (feedhenry, mobile-internal) >> > > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpassos at redhat.com Mon Dec 18 14:37:37 2017 From: dpassos at redhat.com (Daniel Passos) Date: Mon, 18 Dec 2017 12:37:37 -0200 Subject: [feedhenry-dev] Deprecate AeroGear auth libraries Message-ID: Hi, Today we have libraries to handle Auth stuff for HTTP Basic and HTTP Digest, this libraries is no longer maintained for a long time and I think no one is using this kind of Auth anymore. Should we archive it and move to the aerogear-attic[1] [1] https://github.com/aerogear-attic -- -- Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpassos at redhat.com Mon Dec 18 14:37:56 2017 From: dpassos at redhat.com (Daniel Passos) Date: Mon, 18 Dec 2017 12:37:56 -0200 Subject: [feedhenry-dev] AeroGear repos moved to the attic org Message-ID: Hi, I have moved all archive/no longer maintained Android[1], iOS[2] and Cordova[3] libraries to the aerogear-attic[4] repo and deleted those from the aerogear[5] [1] https://github.com/aerogear-attic?utf8=?&q=android [2] https://github.com/aerogear-attic?utf8=?&q=ios [3] https://github.com/aerogear-attic?utf8=?&q=cordova [4] https://github.com/aerogear-attic [5] https://github.com/aerogear -- -- Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpassos at redhat.com Mon Dec 18 14:38:18 2017 From: dpassos at redhat.com (Daniel Passos) Date: Mon, 18 Dec 2017 12:38:18 -0200 Subject: [feedhenry-dev] Deprecated aerogear-cordova-geo Message-ID: Hi, Should we deprecated aerogear-cordova-geo[1]? Cordova is the only one has the Geo library and the last commit on this library was in Sep 7, 2015 [1] https://github.com/aerogear/aerogear-cordova-geo -- -- Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpassos at redhat.com Mon Dec 18 14:38:36 2017 From: dpassos at redhat.com (Daniel Passos) Date: Mon, 18 Dec 2017 12:38:36 -0200 Subject: [feedhenry-dev] AeroGear Windows Libraries support Message-ID: Hi, Should we still supporting Windows libraries? Here is the list of the libraries we have for the Windows platform, there is no update for these for a long time * aerogear-windows-oauth2 * aerogear-windows-push * aerogear-windows-otp -- -- Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: From ngough at redhat.com Mon Dec 18 15:05:12 2017 From: ngough at redhat.com (Nano Gough) Date: Mon, 18 Dec 2017 15:05:12 +0000 Subject: [feedhenry-dev] AeroGear Windows Libraries support In-Reply-To: References: Message-ID: We are in the process of marking these as deprecated with view to formally removing support for windows. On 18 December 2017 at 14:38, Daniel Passos wrote: > Hi, > > Should we still supporting Windows libraries? > > Here is the list of the libraries we have for the Windows platform, there > is no update for these for a long time > > * aerogear-windows-oauth2 > * aerogear-windows-push > * aerogear-windows-otp > > -- > -- Passos > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- Nano Gough Senior Principal Product Manager RedHat Mobile Tel (mob): +353 (0) 86 3651465 ngough at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Mon Dec 18 15:17:01 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Mon, 18 Dec 2017 16:17:01 +0100 Subject: [feedhenry-dev] Deprecate AeroGear auth libraries In-Reply-To: References: Message-ID: +1 On Mon, Dec 18, 2017 at 3:37 PM, Daniel Passos wrote: > Hi, > > Today we have libraries to handle Auth stuff for HTTP Basic and HTTP > Digest, this libraries is no longer maintained for a long time and I think > no one is using this kind of Auth anymore. Should we archive it and move to > the aerogear-attic[1] > > [1] https://github.com/aerogear-attic > > -- > -- Passos > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Mon Dec 18 15:17:21 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Mon, 18 Dec 2017 16:17:21 +0100 Subject: [feedhenry-dev] AeroGear repos moved to the attic org In-Reply-To: References: Message-ID: +1 On Mon, Dec 18, 2017 at 3:37 PM, Daniel Passos wrote: > Hi, > > I have moved all archive/no longer maintained Android[1], iOS[2] and > Cordova[3] libraries to the aerogear-attic[4] repo and deleted those from > the aerogear[5] > > [1] https://github.com/aerogear-attic?utf8=?&q=android > [2] https://github.com/aerogear-attic?utf8=?&q=ios > [3] https://github.com/aerogear-attic?utf8=?&q=cordova > [4] https://github.com/aerogear-attic > [5] https://github.com/aerogear > > > -- > -- Passos > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Mon Dec 18 15:18:02 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Mon, 18 Dec 2017 16:18:02 +0100 Subject: [feedhenry-dev] Deprecated aerogear-cordova-geo In-Reply-To: References: Message-ID: yeah, I'm +1 on that Even if we spin up something new around GEO, we can still borrow/leverage code from here - if really needed On Mon, Dec 18, 2017 at 3:38 PM, Daniel Passos wrote: > Hi, > > Should we deprecated aerogear-cordova-geo[1]? > > Cordova is the only one has the Geo library and the last commit on this > library was in Sep 7, 2015 > > [1] https://github.com/aerogear/aerogear-cordova-geo > > -- > -- Passos > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Mon Dec 18 15:19:39 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Mon, 18 Dec 2017 16:19:39 +0100 Subject: [feedhenry-dev] AeroGear Windows Libraries support In-Reply-To: References: Message-ID: I am not sure on aerogear-windows-push That's used inside our Cordova Push lib And every now and than we do have some Windows stuff on the community The others -> kill em w/ fire On Mon, Dec 18, 2017 at 3:38 PM, Daniel Passos wrote: > Hi, > > Should we still supporting Windows libraries? > > Here is the list of the libraries we have for the Windows platform, there > is no update for these for a long time > > * aerogear-windows-oauth2 > * aerogear-windows-push > * aerogear-windows-otp > > -- > -- Passos > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From matzew at apache.org Mon Dec 18 15:23:34 2017 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 18 Dec 2017 16:23:34 +0100 Subject: [feedhenry-dev] [aerogear-dev] 5.x Local Development In-Reply-To: References: Message-ID: On Mon, Dec 18, 2017 at 12:23 PM, David Martin wrote: > Regarding this step, > > * remove the mcp-standalone service from the Android, iOS & Cordova APBs > > I'll be moving the App APBs to their own individual repos in the > aerogearcatalog github org. > > Reasons: > * All other APBs are in the aerogearcatalog org now > nice! I've slightly modified the build settings Added the "/^[0-9.]+/" regex for TAGs: once we push any tag to GH - it will automatically trigger a matching Docker Hub tag > * The 3 App APBs were responsible for provisioning the mcp-standalone > server. There is no longer a mcp-standalone server, so the need to have > them in the same repo as that server has gone. > > On 18 December 2017 at 09:30, David Martin wrote: > >> Making these changes this today. >> I'll send out another mail with any instructions required once complete. >> >> On 15 December 2017 at 14:01, David Martin wrote: >> >>> Fork & archive sounds good to me. >>> >>> I'll plan to progress these changes on Monday, with a name of >>> 'mobile-core' for the new repo, unless further discussions happen before >>> then >>> >>> On 15 December 2017 at 13:27, Matthias Wessendorf >>> wrote: >>> >>>> >>>> >>>> On Fri 15. Dec 2017 at 12:54, Wojciech Trocki >>>> wrote: >>>> >>>>> +1 >>>>> >>>>> * remove the mcp server >>>>>> >>>>> >>>>> Can we move that to new attic organization to have future reference if >>>>> needed? >>>>> >>>> >>>> for me the attic is really for old AeroGear stuff >>>> >>>> How about we fork 'mcp-standalone' into aerogear, and work on it there >>>> - while keeping the original repo (archived / read-only) in feedhenry ? >>>> >>>> >>>>> >>>>> -- >>>>> >>>>> WOJCIECH TROCKI >>>>> >>>>> Red Hat Mobile >>>>> >>>>> IM: wtrocki >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>> >>> >>> -- >>> David Martin >>> Red Hat Mobile >>> Twitter: @irldavem >>> IRC: @irldavem (feedhenry, mobile-internal) >>> >> >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (feedhenry, mobile-internal) >> > > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) > -- Matthias Wessendorf github: https://github.com/matzew twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Mon Dec 18 16:13:48 2017 From: davmarti at redhat.com (David Martin) Date: Mon, 18 Dec 2017 16:13:48 +0000 Subject: [feedhenry-dev] [aerogear-dev] 5.x Local Development In-Reply-To: References: Message-ID: Thanks Matthias. That makes sense. I've finished with what I set out to do now. The new repo is available here https://github.com/aerogear/mobile-core, but I'll start a new thread for ironing out any issues with it, and giving more context on what's changed. On 18 December 2017 at 15:23, Matthias Wessendorf wrote: > > > On Mon, Dec 18, 2017 at 12:23 PM, David Martin > wrote: > >> Regarding this step, >> >> * remove the mcp-standalone service from the Android, iOS & Cordova APBs >> >> I'll be moving the App APBs to their own individual repos in the >> aerogearcatalog github org. >> >> Reasons: >> * All other APBs are in the aerogearcatalog org now >> > > nice! > I've slightly modified the build settings > > Added the "/^[0-9.]+/" regex for TAGs: once we push any tag to GH - it > will automatically trigger a matching Docker Hub tag > > >> * The 3 App APBs were responsible for provisioning the mcp-standalone >> server. There is no longer a mcp-standalone server, so the need to have >> them in the same repo as that server has gone. >> >> On 18 December 2017 at 09:30, David Martin wrote: >> >>> Making these changes this today. >>> I'll send out another mail with any instructions required once complete. >>> >>> On 15 December 2017 at 14:01, David Martin wrote: >>> >>>> Fork & archive sounds good to me. >>>> >>>> I'll plan to progress these changes on Monday, with a name of >>>> 'mobile-core' for the new repo, unless further discussions happen before >>>> then >>>> >>>> On 15 December 2017 at 13:27, Matthias Wessendorf >>>> wrote: >>>> >>>>> >>>>> >>>>> On Fri 15. Dec 2017 at 12:54, Wojciech Trocki >>>>> wrote: >>>>> >>>>>> +1 >>>>>> >>>>>> * remove the mcp server >>>>>>> >>>>>> >>>>>> Can we move that to new attic organization to have future reference >>>>>> if needed? >>>>>> >>>>> >>>>> for me the attic is really for old AeroGear stuff >>>>> >>>>> How about we fork 'mcp-standalone' into aerogear, and work on it there >>>>> - while keeping the original repo (archived / read-only) in feedhenry ? >>>>> >>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> WOJCIECH TROCKI >>>>>> >>>>>> Red Hat Mobile >>>>>> >>>>>> IM: wtrocki >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> David Martin >>>> Red Hat Mobile >>>> Twitter: @irldavem >>>> IRC: @irldavem (feedhenry, mobile-internal) >>>> >>> >>> >>> >>> -- >>> David Martin >>> Red Hat Mobile >>> Twitter: @irldavem >>> IRC: @irldavem (feedhenry, mobile-internal) >>> >> >> >> >> -- >> David Martin >> Red Hat Mobile >> Twitter: @irldavem >> IRC: @irldavem (feedhenry, mobile-internal) >> > > > > -- > Matthias Wessendorf > > github: https://github.com/matzew > twitter: http://twitter.com/mwessendorf > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Mon Dec 18 16:18:11 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Mon, 18 Dec 2017 17:18:11 +0100 Subject: [feedhenry-dev] [aerogear-dev] 5.x Local Development In-Reply-To: References: Message-ID: On Mon, Dec 18, 2017 at 5:13 PM, David Martin wrote: > Thanks Matthias. > That makes sense. > > I've finished with what I set out to do now. > The new repo is available here https://github.com/aerogear/mobile-core, > but I'll start a new thread for ironing out any issues with it, and giving > more context on what's changed. > +1 for a new thread ;-) > > > On 18 December 2017 at 15:23, Matthias Wessendorf > wrote: > >> >> >> On Mon, Dec 18, 2017 at 12:23 PM, David Martin >> wrote: >> >>> Regarding this step, >>> >>> * remove the mcp-standalone service from the Android, iOS & Cordova APBs >>> >>> I'll be moving the App APBs to their own individual repos in the >>> aerogearcatalog github org. >>> >>> Reasons: >>> * All other APBs are in the aerogearcatalog org now >>> >> >> nice! >> I've slightly modified the build settings >> >> Added the "/^[0-9.]+/" regex for TAGs: once we push any tag to GH - it >> will automatically trigger a matching Docker Hub tag >> >> >>> * The 3 App APBs were responsible for provisioning the mcp-standalone >>> server. There is no longer a mcp-standalone server, so the need to have >>> them in the same repo as that server has gone. >>> >>> On 18 December 2017 at 09:30, David Martin wrote: >>> >>>> Making these changes this today. >>>> I'll send out another mail with any instructions required once complete. >>>> >>>> On 15 December 2017 at 14:01, David Martin wrote: >>>> >>>>> Fork & archive sounds good to me. >>>>> >>>>> I'll plan to progress these changes on Monday, with a name of >>>>> 'mobile-core' for the new repo, unless further discussions happen before >>>>> then >>>>> >>>>> On 15 December 2017 at 13:27, Matthias Wessendorf >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Fri 15. Dec 2017 at 12:54, Wojciech Trocki >>>>>> wrote: >>>>>> >>>>>>> +1 >>>>>>> >>>>>>> * remove the mcp server >>>>>>>> >>>>>>> >>>>>>> Can we move that to new attic organization to have future reference >>>>>>> if needed? >>>>>>> >>>>>> >>>>>> for me the attic is really for old AeroGear stuff >>>>>> >>>>>> How about we fork 'mcp-standalone' into aerogear, and work on it >>>>>> there - while keeping the original repo (archived / read-only) in feedhenry >>>>>> ? >>>>>> >>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> WOJCIECH TROCKI >>>>>>> >>>>>>> Red Hat Mobile >>>>>>> >>>>>>> IM: wtrocki >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> David Martin >>>>> Red Hat Mobile >>>>> Twitter: @irldavem >>>>> IRC: @irldavem (feedhenry, mobile-internal) >>>>> >>>> >>>> >>>> >>>> -- >>>> David Martin >>>> Red Hat Mobile >>>> Twitter: @irldavem >>>> IRC: @irldavem (feedhenry, mobile-internal) >>>> >>> >>> >>> >>> -- >>> David Martin >>> Red Hat Mobile >>> Twitter: @irldavem >>> IRC: @irldavem (feedhenry, mobile-internal) >>> >> >> >> >> -- >> Matthias Wessendorf >> >> github: https://github.com/matzew >> twitter: http://twitter.com/mwessendorf >> > > > > -- > 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 > > -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmarti at redhat.com Mon Dec 18 16:25:21 2017 From: davmarti at redhat.com (David Martin) Date: Mon, 18 Dec 2017 16:25:21 +0000 Subject: [feedhenry-dev] (ACTION REQUIRED) 5.x Local Development Message-ID: Hi, As mentioned in the mail thread [1], some changes have been made wrt 5.x local development. TLDR * Please clone the repo at https://github.com/aerogear/mobile-core * Follow the Local Setup guide as detailed in https://github.com/aerogear/mobile-core/blob/master/docs/walkthroughs/local-setup.adoc * Shout (via this thread, #aerogear or a PR) if you find any issues around local development Long version The repo at https://github.com/feedhenry/mcp-standalone has been archived as is no longer maintained A fork of this repo was made (https://github.com/aerogear/mobile-core), and some reasonable size changes were made to it: * removed the mcp server * moved the Andoird, iOS & Cordova APBs to their own repos [2][3][4] with build jobs setup on Docker Hub in the aerogearcatalog org ** these APBs now just create a configmap to represent the App * removed the Mobile Tab from the UI * removed a bunch of docs mostly relevant to the POC * updated the local setup docs to make them relevant for local development going forward * updated the local install to use 'aerogearcatalog' as the default dockerhub org for APBs [1] http://lists.jboss.org/pipermail/aerogear-dev/2017-December/013158.html [2] https://github.com/aerogearcatalog/android-app-apb [3] https://github.com/aerogearcatalog/ios-app-apb [4] https://github.com/aerogearcatalog/cordova-app-apb -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwright at redhat.com Mon Dec 18 20:04:08 2017 From: pwright at redhat.com (Paul Wright) Date: Mon, 18 Dec 2017 20:04:08 +0000 Subject: [feedhenry-dev] Suggestion/Discussion - Removal of AeroGear.org Production Branch Message-ID: <8bdb3c64-3b82-0b77-38aa-93ee836954df@redhat.com> Hi Laura, All, I'd like to follow up about the suggestion of a new site, thinking specifically about: * much of the existing content is out of date * there is a lot of 'formerly feedhenry) material to be published next year (eg mcp, sync) * the rendering toolchain is sub-optimal (in my POV) * big changes are happening anyway (now is the opportunity) However I'm not sure if this means? revamping? aerogear.org or the introduction of a new site docs.aerogear.org ? So, let me propose this, which is what I'd like to see: * Versioned docs for each component * A doc set for combining a set of components into a release * An asciidoc-first approach to the docs (altho I'd like to see markdown still supported for blogs/etc) With this in mind, I'm playing with asciibinder, for example, see the digger docs [1], this has the advantage: * it's what OpenShift uses * it's geared towards complex doc sets * it's geared to multiple version doc sets * it's lightweight and gathering some momentum (eg fedora are now using it) Maybe it's used for everything but the home page as per OS [2] Or maybe the existing aerogear.org lives on, and users only hit the asciibinder html at a lower level? WDYT? thanks, Paul [1] https://5-114535426-gh.circle-artifacts.com/0/home/circleci/docs/_preview/digger/latest/installation/digger-install-intro.html [2] https://docs.openshift.com/ Date: Fri, 15 Dec 2017 13:56:57 +0000 From: Laura Fitzgerald To: AeroGear Developer Mailing List, feedhenry-dev at redhat.com Subject: Re: [feedhenry-dev] Suggestion/Discussion - Removal of AeroGear.org Production Branch Message-ID: Content-Type: text/plain; charset="utf-8" Hi all, I had sent this email re improving the way that we pubish aerogear.org. Some may have seen it and replied but as there is some problems with aerogear-dev mailing and there has been some further discussions I wanted to reopen a conversation re Aerogear.org. With the move to the aerogear org there has been some conversation aroung an overhaul of the aerogear.org website. It was also suggested that we could go with a brand new site rather than rejigging the old site. I'm thinking that it would be worth having a discussion around how we would go about this. If anyone has particular interest in this and/or experience with the old site and existing tech and wants to open a proposal/discussion re tech stack, design, content etc I think it would be suitable to to do that via the proposals repo [1] or via some discussion here. I've been involved in adding some content recently with the Aerogear Digger Project and my vote would be for creating something new and shiny!!! Wdy guys t? [1]https://github.com/aerogear/proposals On Wed, Dec 6, 2017 at 11:07 AM, Laura Fitzgerald wrote: > Hi all, > > I have recently gone through the process of publishing documentation for > AeroGear Digger to aerogear.org. > > The process for adding docs for digger was as follows: > > - Make changes on Feature Branch over a period of time. > - At some point merge lots of commits (difficult to review) from Feature > Branch to master. > - This publishes to staging.aerogear.org (build needs to be manually > triggered in Jenkins) > - At some point merge master (again with lots of commits) to production > branch > - This publishes to aerogear.org (build needs to be manually triggered) > > Out of this we attempted to improve the process by adding development > steps to the README [1] outlining that > -> each change should be verified on it's own -> merged to master -> and > then merged to production > removing the wait time and merges which involved lots of commits and > changes. > > *I think there are a few things we can do to make this better. (simpler)* > > *1) How?* > > Remove the production branch (and related steps) altogether. > > *Why?* > > - All this documentation is done in the open. > - All branches are visible to all users/developers. > - staging.aerogear.org is not private so I don't see that we gain > something by having this step. > - Changes can be verified locally by building the website using the steps > in the README [2] before being merged to master. > > *2) How?* > Automate the publishing of the site > > *Why?* > Right now the building of the site has to be triggered manually via a > Jenkins instance on cloudbees. If we remove production and enforce that all > changes are fully verified before being merged to master then we can > automate that any new changes are published immediately once merged to > master. > > *3) How?* > Add some sort of versioning to the documentation. This could be in the > form of tagging the repo once we have a release of a product. > > *Why?* > If we are always publishing docs once a change is made to the product then > we should version the documentation so we know which version of the docs > matches older versions of the product. > > ~~~~~~~~~~~ > > I'm really interested in some feedback on this. Let me know what you > think. Is there a better/simpler way to do it than I suggested? > > [1]https://github.com/aerogear/aerogear.org/blob/ > master/README.md#development-steps > [2]https://github.com/aerogear/aerogear.org/blob/ > master/README.md#building > -- > > LAURA FITZGERALD > > Red Hat Mobile > > Communications House, Cork Road > > Waterford City, Ireland X91NY33 > > lfitzger at redhat.com IM: lfitzgerald > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Tue Dec 19 09:34:19 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Tue, 19 Dec 2017 09:34:19 +0000 Subject: [feedhenry-dev] Suggestion/Discussion - Removal of AeroGear.org Production Branch In-Reply-To: <8bdb3c64-3b82-0b77-38aa-93ee836954df@redhat.com> References: <8bdb3c64-3b82-0b77-38aa-93ee836954df@redhat.com> Message-ID: +1 for kicking out some investigations. Let me know if you need something specific. I see that most of the JBoos products now using ascidocs based documentation. For example: http://www.keycloak.org/docs/latest/getting_started/index.html https://docs.jboss.org/jbpm/release/7.4.1.Final/jbpm-docs/html_single > However I'm not sure if this means revamping aerogear.org or the introduction of a new site docs.aerogear.org ? Aerogear is project aggregator website so aproach will need to be different than when building webpage for single project. IMHO best is to refresh aerogear webpage layout to support project subpages. For example aerogear.org/sync aerogear.org/digger Example layout: [image: Inline image 1] Then each of this subpages can have general information, links to documentation, supported versions etc. This aproach is really common for open source projects aggregators. On Mon, Dec 18, 2017 at 8:04 PM, Paul Wright wrote: > Hi Laura, All, > I'd like to follow up about the suggestion of a new site, thinking > specifically about: > * much of the existing content is out of date > * there is a lot of 'formerly feedhenry) material to be published next > year (eg mcp, sync) > * the rendering toolchain is sub-optimal (in my POV) > * big changes are happening anyway (now is the opportunity) > > However I'm not sure if this means revamping aerogear.org or the > introduction of a new site docs.aerogear.org ? > So, let me propose this, which is what I'd like to see: > > * Versioned docs for each component > * A doc set for combining a set of components into a release > * An asciidoc-first approach to the docs (altho I'd like to see markdown > still supported for blogs/etc) > > With this in mind, I'm playing with asciibinder, for example, see the > digger docs [1], this has the advantage: > > * it's what OpenShift uses > * it's geared towards complex doc sets > * it's geared to multiple version doc sets > * it's lightweight and gathering some momentum (eg fedora are now using it) > > Maybe it's used for everything but the home page as per OS [2] > > Or maybe the existing aerogear.org lives on, and users only hit the > asciibinder html at a lower level? > > WDYT? > > thanks, > Paul > > > [1] https://5-114535426-gh.circle-artifacts.com/0/home/circleci/ > docs/_preview/digger/latest/installation/digger-install-intro.html > > [2] https://docs.openshift.com/ > > > Date: Fri, 15 Dec 2017 13:56:57 +0000 > From: Laura Fitzgerald > To: AeroGear Developer Mailing List , > feedhenry-dev at redhat.com > Subject: Re: [feedhenry-dev] Suggestion/Discussion - Removal of > AeroGear.org Production Branch > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > Hi all, > > I had sent this email re improving the way that we pubish aerogear.org. > Some may have seen it and replied but as there is some problems with > aerogear-dev mailing and there has been some further discussions I wanted > to reopen a conversation re Aerogear.org. > > With the move to the aerogear org there has been some conversation aroung > an overhaul of the aerogear.org website. > > It was also suggested that we could go with a brand new site rather than > rejigging the old site. > > I'm thinking that it would be worth having a discussion around how we would > go about this. > > If anyone has particular interest in this and/or experience with the old > site and existing tech and wants to open a proposal/discussion re tech > stack, design, content etc I think it would be suitable to to do that via > the proposals repo [1] or via some discussion here. > > I've been involved in adding some content recently with the Aerogear Digger > Project and my vote would be for creating something new and shiny!!! > > Wdy guys t? > > [1] https://github.com/aerogear/proposals > > On Wed, Dec 6, 2017 at 11:07 AM, Laura Fitzgerald > wrote: > > > Hi all, > > I have recently gone through the process of publishing documentation for > AeroGear Digger to aerogear.org. > > The process for adding docs for digger was as follows: > > - Make changes on Feature Branch over a period of time. > - At some point merge lots of commits (difficult to review) from Feature > Branch to master. > - This publishes to staging.aerogear.org (build needs to be manually > triggered in Jenkins) > - At some point merge master (again with lots of commits) to production > branch > - This publishes to aerogear.org (build needs to be manually triggered) > > Out of this we attempted to improve the process by adding development > steps to the README [1] outlining that > -> each change should be verified on it's own -> merged to master -> and > then merged to production > removing the wait time and merges which involved lots of commits and > changes. > > *I think there are a few things we can do to make this better. (simpler)* > > *1) How?* > > Remove the production branch (and related steps) altogether. > > *Why?* > > - All this documentation is done in the open. > - All branches are visible to all users/developers. > - staging.aerogear.org is not private so I don't see that we gain > something by having this step. > - Changes can be verified locally by building the website using the steps > in the README [2] before being merged to master. > > *2) How?* > Automate the publishing of the site > > *Why?* > Right now the building of the site has to be triggered manually via a > Jenkins instance on cloudbees. If we remove production and enforce that all > changes are fully verified before being merged to master then we can > automate that any new changes are published immediately once merged to > master. > > *3) How?* > Add some sort of versioning to the documentation. This could be in the > form of tagging the repo once we have a release of a product. > > *Why?* > If we are always publishing docs once a change is made to the product then > we should version the documentation so we know which version of the docs > matches older versions of the product. > > ~~~~~~~~~~~ > > I'm really interested in some feedback on this. Let me know what you > think. Is there a better/simpler way to do it than I suggested? > > [1] https://github.com/aerogear/aerogear.org/blob/ > master/README.md#development-steps > [2] https://github.com/aerogear/aerogear.org/blob/ > master/README.md#building > -- > > LAURA FITZGERALD > > Red Hat Mobile > > Communications House, Cork Road > > Waterford City, Ireland X91NY33 > lfitzger at redhat.com IM: lfitzgerald > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- WOJCIECH TROCKI Red Hat Mobile IM: wtrocki -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2017-12-19 at 9.28.29 AM.png Type: image/png Size: 300684 bytes Desc: not available URL: From davmarti at redhat.com Tue Dec 19 09:46:45 2017 From: davmarti at redhat.com (David Martin) Date: Tue, 19 Dec 2017 09:46:45 +0000 Subject: [feedhenry-dev] Suggestion/Discussion - Removal of AeroGear.org Production Branch In-Reply-To: References: <8bdb3c64-3b82-0b77-38aa-93ee836954df@redhat.com> Message-ID: I like the idea of a custom landing page, and using asciibinder thereafter for all docs. The landing page would initially function as a gateway to the upstream docs, and any other upstream content (e.g. contributing guide) Adding downstream or other version of docs could come later. @Paul, @Laura What would be involved in converting the existing Aerogear docs into asciidoc and getting them working with asciibinder? It would make sense to leave behind docs for anything deprecated or no longer maintained. Updating any docs (e.g. UPS) could be a task for after the initial 'getting things working with asciibinder'. Similarly, moving Sync docs could be a task after the initial work. On 19 December 2017 at 09:34, Wojciech Trocki wrote: > +1 for kicking out some investigations. > Let me know if you need something specific. > I see that most of the JBoos products now using ascidocs based > documentation. > > For example: > http://www.keycloak.org/docs/latest/getting_started/index.html > https://docs.jboss.org/jbpm/release/7.4.1.Final/jbpm-docs/html_single > > > > However I'm not sure if this means revamping aerogear.org or the > introduction of a new site docs.aerogear.org ? > > Aerogear is project aggregator website so aproach will need to be > different than when building webpage for single project. > IMHO best is to refresh aerogear webpage layout to support project > subpages. For example > > aerogear.org/sync > aerogear.org/digger > > Example layout: > > [image: Inline image 1] > Then each of this subpages can have general information, links to > documentation, supported versions etc. > This aproach is really common for open source projects aggregators. > > > On Mon, Dec 18, 2017 at 8:04 PM, Paul Wright wrote: > >> Hi Laura, All, >> I'd like to follow up about the suggestion of a new site, thinking >> specifically about: >> * much of the existing content is out of date >> * there is a lot of 'formerly feedhenry) material to be published next >> year (eg mcp, sync) >> * the rendering toolchain is sub-optimal (in my POV) >> * big changes are happening anyway (now is the opportunity) >> >> However I'm not sure if this means revamping aerogear.org or the >> introduction of a new site docs.aerogear.org ? >> So, let me propose this, which is what I'd like to see: >> >> * Versioned docs for each component >> * A doc set for combining a set of components into a release >> * An asciidoc-first approach to the docs (altho I'd like to see markdown >> still supported for blogs/etc) >> >> With this in mind, I'm playing with asciibinder, for example, see the >> digger docs [1], this has the advantage: >> >> * it's what OpenShift uses >> * it's geared towards complex doc sets >> * it's geared to multiple version doc sets >> * it's lightweight and gathering some momentum (eg fedora are now using >> it) >> >> Maybe it's used for everything but the home page as per OS [2] >> >> Or maybe the existing aerogear.org lives on, and users only hit the >> asciibinder html at a lower level? >> >> WDYT? >> >> thanks, >> Paul >> >> >> [1] https://5-114535426-gh.circle-artifacts.com/0/home/circleci/ >> docs/_preview/digger/latest/installation/digger-install-intro.html >> >> [2] https://docs.openshift.com/ >> >> Date: Fri, 15 Dec 2017 13:56:57 +0000 >> From: Laura Fitzgerald >> To: AeroGear Developer Mailing List , >> feedhenry-dev at redhat.com >> Subject: Re: [feedhenry-dev] Suggestion/Discussion - Removal of >> AeroGear.org Production Branch >> Message-ID: >> >> Content-Type: text/plain; charset="utf-8" >> >> Hi all, >> >> I had sent this email re improving the way that we pubish aerogear.org. >> Some may have seen it and replied but as there is some problems with >> aerogear-dev mailing and there has been some further discussions I wanted >> to reopen a conversation re Aerogear.org. >> >> With the move to the aerogear org there has been some conversation aroung >> an overhaul of the aerogear.org website. >> >> It was also suggested that we could go with a brand new site rather than >> rejigging the old site. >> >> I'm thinking that it would be worth having a discussion around how we would >> go about this. >> >> If anyone has particular interest in this and/or experience with the old >> site and existing tech and wants to open a proposal/discussion re tech >> stack, design, content etc I think it would be suitable to to do that via >> the proposals repo [1] or via some discussion here. >> >> I've been involved in adding some content recently with the Aerogear Digger >> Project and my vote would be for creating something new and shiny!!! >> >> Wdy guys t? >> >> [1] https://github.com/aerogear/proposals >> >> On Wed, Dec 6, 2017 at 11:07 AM, Laura Fitzgerald >> wrote: >> >> >> Hi all, >> >> I have recently gone through the process of publishing documentation for >> AeroGear Digger to aerogear.org. >> >> The process for adding docs for digger was as follows: >> >> - Make changes on Feature Branch over a period of time. >> - At some point merge lots of commits (difficult to review) from Feature >> Branch to master. >> - This publishes to staging.aerogear.org (build needs to be manually >> triggered in Jenkins) >> - At some point merge master (again with lots of commits) to production >> branch >> - This publishes to aerogear.org (build needs to be manually triggered) >> >> Out of this we attempted to improve the process by adding development >> steps to the README [1] outlining that >> -> each change should be verified on it's own -> merged to master -> and >> then merged to production >> removing the wait time and merges which involved lots of commits and >> changes. >> >> *I think there are a few things we can do to make this better. (simpler)* >> >> *1) How?* >> >> Remove the production branch (and related steps) altogether. >> >> *Why?* >> >> - All this documentation is done in the open. >> - All branches are visible to all users/developers. >> - staging.aerogear.org is not private so I don't see that we gain >> something by having this step. >> - Changes can be verified locally by building the website using the steps >> in the README [2] before being merged to master. >> >> *2) How?* >> Automate the publishing of the site >> >> *Why?* >> Right now the building of the site has to be triggered manually via a >> Jenkins instance on cloudbees. If we remove production and enforce that all >> changes are fully verified before being merged to master then we can >> automate that any new changes are published immediately once merged to >> master. >> >> *3) How?* >> Add some sort of versioning to the documentation. This could be in the >> form of tagging the repo once we have a release of a product. >> >> *Why?* >> If we are always publishing docs once a change is made to the product then >> we should version the documentation so we know which version of the docs >> matches older versions of the product. >> >> ~~~~~~~~~~~ >> >> I'm really interested in some feedback on this. Let me know what you >> think. Is there a better/simpler way to do it than I suggested? >> >> [1] https://github.com/aerogear/aerogear.org/blob/ >> master/README.md#development-steps >> [2] https://github.com/aerogear/aerogear.org/blob/ >> master/README.md#building >> -- >> >> LAURA FITZGERALD >> >> Red Hat Mobile >> >> Communications House, Cork Road >> >> Waterford City, Ireland X91NY33 >> lfitzger at redhat.com IM: lfitzgerald >> >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > > WOJCIECH TROCKI > > Red Hat Mobile > > IM: wtrocki > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2017-12-19 at 9.28.29 AM.png Type: image/png Size: 300684 bytes Desc: not available URL: From wtrocki at redhat.com Tue Dec 19 09:48:05 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Tue, 19 Dec 2017 09:48:05 +0000 Subject: [feedhenry-dev] Suggestion/Discussion - Removal of AeroGear.org Production Branch In-Reply-To: References: <8bdb3c64-3b82-0b77-38aa-93ee836954df@redhat.com> Message-ID: +1 for kicking out some investigations. Let me know if you need something specific. I see that most of the JBoos products now using ascidocs based documentation. For example: http://www.keycloak.org/docs/latest/getting_started/index.html https://docs.jboss.org/jbpm/release/7.4.1.Final/jbpm-docs/html_single > However I'm not sure if this means revamping aerogear.org or the introduction of a new site docs.aerogear.org ? Aerogear is project aggregator website so aproach will need to be different than when building webpage for single project. IMHO best is to refresh aerogear webpage layout to support project subpages. For example aerogear.org/sync aerogear.org/digger Example layout: https://imgur.com/a/2uBrN Then each of this subpages can have general information, links to documentation, supported versions etc. This aproach is really common for open source projects aggregators. On Tue, Dec 19, 2017 at 9:46 AM, David Martin wrote: > I like the idea of a custom landing page, and using asciibinder thereafter > for all docs. > The landing page would initially function as a gateway to the upstream > docs, and any other upstream content (e.g. contributing guide) > Adding downstream or other version of docs could come later. > > @Paul, @Laura What would be involved in converting the existing Aerogear > docs into asciidoc and getting them working with asciibinder? > It would make sense to leave behind docs for anything deprecated or no > longer maintained. > > Updating any docs (e.g. UPS) could be a task for after the initial > 'getting things working with asciibinder'. > Similarly, moving Sync docs could be a task after the initial work. > > > On 19 December 2017 at 09:34, Wojciech Trocki wrote: > >> +1 for kicking out some investigations. >> Let me know if you need something specific. >> I see that most of the JBoos products now using ascidocs based >> documentation. >> >> For example: >> http://www.keycloak.org/docs/latest/getting_started/index.html >> https://docs.jboss.org/jbpm/release/7.4.1.Final/jbpm-docs/html_single >> >> >> > However I'm not sure if this means revamping aerogear.org or the >> introduction of a new site docs.aerogear.org ? >> >> Aerogear is project aggregator website so aproach will need to be >> different than when building webpage for single project. >> IMHO best is to refresh aerogear webpage layout to support project >> subpages. For example >> >> aerogear.org/sync >> aerogear.org/digger >> >> Example layout: >> >> [image: Inline image 1] >> Then each of this subpages can have general information, links to >> documentation, supported versions etc. >> This aproach is really common for open source projects aggregators. >> >> >> On Mon, Dec 18, 2017 at 8:04 PM, Paul Wright wrote: >> >>> Hi Laura, All, >>> I'd like to follow up about the suggestion of a new site, thinking >>> specifically about: >>> * much of the existing content is out of date >>> * there is a lot of 'formerly feedhenry) material to be published next >>> year (eg mcp, sync) >>> * the rendering toolchain is sub-optimal (in my POV) >>> * big changes are happening anyway (now is the opportunity) >>> >>> However I'm not sure if this means revamping aerogear.org or the >>> introduction of a new site docs.aerogear.org ? >>> So, let me propose this, which is what I'd like to see: >>> >>> * Versioned docs for each component >>> * A doc set for combining a set of components into a release >>> * An asciidoc-first approach to the docs (altho I'd like to see markdown >>> still supported for blogs/etc) >>> >>> With this in mind, I'm playing with asciibinder, for example, see the >>> digger docs [1], this has the advantage: >>> >>> * it's what OpenShift uses >>> * it's geared towards complex doc sets >>> * it's geared to multiple version doc sets >>> * it's lightweight and gathering some momentum (eg fedora are now using >>> it) >>> >>> Maybe it's used for everything but the home page as per OS [2] >>> >>> Or maybe the existing aerogear.org lives on, and users only hit the >>> asciibinder html at a lower level? >>> >>> WDYT? >>> >>> thanks, >>> Paul >>> >>> >>> [1] https://5-114535426-gh.circle-artifacts.com/0/home/circleci/ >>> docs/_preview/digger/latest/installation/digger-install-intro.html >>> >>> [2] https://docs.openshift.com/ >>> >>> Date: Fri, 15 Dec 2017 13:56:57 +0000 >>> From: Laura Fitzgerald >>> To: AeroGear Developer Mailing List , >>> feedhenry-dev at redhat.com >>> Subject: Re: [feedhenry-dev] Suggestion/Discussion - Removal of >>> AeroGear.org Production Branch >>> Message-ID: >>> >>> Content-Type: text/plain; charset="utf-8" >>> >>> Hi all, >>> >>> I had sent this email re improving the way that we pubish aerogear.org. >>> Some may have seen it and replied but as there is some problems with >>> aerogear-dev mailing and there has been some further discussions I wanted >>> to reopen a conversation re Aerogear.org. >>> >>> With the move to the aerogear org there has been some conversation aroung >>> an overhaul of the aerogear.org website. >>> >>> It was also suggested that we could go with a brand new site rather than >>> rejigging the old site. >>> >>> I'm thinking that it would be worth having a discussion around how we would >>> go about this. >>> >>> If anyone has particular interest in this and/or experience with the old >>> site and existing tech and wants to open a proposal/discussion re tech >>> stack, design, content etc I think it would be suitable to to do that via >>> the proposals repo [1] or via some discussion here. >>> >>> I've been involved in adding some content recently with the Aerogear Digger >>> Project and my vote would be for creating something new and shiny!!! >>> >>> Wdy guys t? >>> >>> [1] https://github.com/aerogear/proposals >>> >>> On Wed, Dec 6, 2017 at 11:07 AM, Laura Fitzgerald >>> wrote: >>> >>> >>> Hi all, >>> >>> I have recently gone through the process of publishing documentation for >>> AeroGear Digger to aerogear.org. >>> >>> The process for adding docs for digger was as follows: >>> >>> - Make changes on Feature Branch over a period of time. >>> - At some point merge lots of commits (difficult to review) from Feature >>> Branch to master. >>> - This publishes to staging.aerogear.org (build needs to be manually >>> triggered in Jenkins) >>> - At some point merge master (again with lots of commits) to production >>> branch >>> - This publishes to aerogear.org (build needs to be manually triggered) >>> >>> Out of this we attempted to improve the process by adding development >>> steps to the README [1] outlining that >>> -> each change should be verified on it's own -> merged to master -> and >>> then merged to production >>> removing the wait time and merges which involved lots of commits and >>> changes. >>> >>> *I think there are a few things we can do to make this better. (simpler)* >>> >>> *1) How?* >>> >>> Remove the production branch (and related steps) altogether. >>> >>> *Why?* >>> >>> - All this documentation is done in the open. >>> - All branches are visible to all users/developers. >>> - staging.aerogear.org is not private so I don't see that we gain >>> something by having this step. >>> - Changes can be verified locally by building the website using the steps >>> in the README [2] before being merged to master. >>> >>> *2) How?* >>> Automate the publishing of the site >>> >>> *Why?* >>> Right now the building of the site has to be triggered manually via a >>> Jenkins instance on cloudbees. If we remove production and enforce that all >>> changes are fully verified before being merged to master then we can >>> automate that any new changes are published immediately once merged to >>> master. >>> >>> *3) How?* >>> Add some sort of versioning to the documentation. This could be in the >>> form of tagging the repo once we have a release of a product. >>> >>> *Why?* >>> If we are always publishing docs once a change is made to the product then >>> we should version the documentation so we know which version of the docs >>> matches older versions of the product. >>> >>> ~~~~~~~~~~~ >>> >>> I'm really interested in some feedback on this. Let me know what you >>> think. Is there a better/simpler way to do it than I suggested? >>> >>> [1] https://github.com/aerogear/aerogear.org/blob/ >>> master/README.md#development-steps >>> [2] https://github.com/aerogear/aerogear.org/blob/ >>> master/README.md#building >>> -- >>> >>> LAURA FITZGERALD >>> >>> Red Hat Mobile >>> >>> Communications House, Cork Road >>> >>> Waterford City, Ireland X91NY33 >>> lfitzger at redhat.com IM: lfitzgerald >>> >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> >> WOJCIECH TROCKI >> >> Red Hat Mobile >> >> IM: wtrocki >> >> >> _______________________________________________ >> 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) > -- WOJCIECH TROCKI Red Hat Mobile IM: wtrocki -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2017-12-19 at 9.28.29 AM.png Type: image/png Size: 300684 bytes Desc: not available URL: From pwright at redhat.com Tue Dec 19 12:37:02 2017 From: pwright at redhat.com (Paul Wright) Date: Tue, 19 Dec 2017 12:37:02 +0000 Subject: [feedhenry-dev] Suggestion/Discussion - Removal of AeroGear.org Production Branch In-Reply-To: References: <8bdb3c64-3b82-0b77-38aa-93ee836954df@redhat.com> Message-ID: Hi, On 12/19/2017 09:46 AM, David Martin wrote: > I like the idea of a custom landing page, and using asciibinder > thereafter for all docs. > The landing page would initially function as a gateway to the upstream > docs, and any other upstream content (e.g. contributing guide) > Adding downstream or other version of docs could come later. > > @Paul, @Laura What would be involved in converting the existing > Aerogear docs into asciidoc and getting them working with asciibinder? Good news! Digger doc is already in asciidoc (altho some work required, eg file suffix, include syntax is non-standard) re. Push, I'm thinking this is the major piece? https://aerogear.org/docs/unifiedpush/ups_userguide/index/ I'll convert that to asciidoc as a first step in this journey > It would make sense to leave behind docs for anything deprecated or no > longer maintained. How would that work? a link to 'Old site'? > > Updating any docs (e.g.? UPS) could be a task for after the initial > 'getting things working with asciibinder'. > Similarly, moving Sync docs could be a task after the initial work. > > > On 19 December 2017 at 09:34, Wojciech Trocki > wrote: > > +1 for kicking out some investigations. > Let me know if you need something specific. > I see that most of the JBoos products now using ascidocs based > documentation. > > For example: > http://www.keycloak.org/docs/latest/getting_started/index.html > > https://docs.jboss.org/jbpm/release/7.4.1.Final/jbpm-docs/html_single > > > > > However I'm not sure if this means? revamping aerogear.org > ?or the introduction of a new site > docs.aerogear.org ?? > > Aerogear is project aggregator website so aproach will need to be > different than when building webpage for single project. > IMHO best is to refresh aerogear webpage layout to support project > subpages. For example > > aerogear.org/sync > aerogear.org/digger > > Example layout: > > Inline image 1 > Then each of this subpages can have general information, links to > documentation, supported versions etc. > This aproach is really common for open source projects aggregators. > > > On Mon, Dec 18, 2017 at 8:04 PM, Paul Wright > wrote: > > Hi Laura, All, > I'd like to follow up about the suggestion of a new site, > thinking specifically about: > * much of the existing content is out of date > * there is a lot of 'formerly feedhenry) material to be > published next year (eg mcp, sync) > * the rendering toolchain is sub-optimal (in my POV) > * big changes are happening anyway (now is the opportunity) > > However I'm not sure if this means? revamping aerogear.org > or the introduction of a new site > docs.aerogear.org ? > So, let me propose this, which is what I'd like to see: > > * Versioned docs for each component > * A doc set for combining a set of components into a release > * An asciidoc-first approach to the docs (altho I'd like to > see markdown still supported for blogs/etc) > > With this in mind, I'm playing with asciibinder, for example, > see the digger docs [1], this has the advantage: > > * it's what OpenShift uses > * it's geared towards complex doc sets > * it's geared to multiple version doc sets > * it's lightweight and gathering some momentum (eg fedora are > now using it) > > Maybe it's used for everything but the home page as per OS [2] > > Or maybe the existing aerogear.org lives > on, and users only hit the asciibinder html at a lower level? > > WDYT? > > thanks, > Paul > > > [1] > https://5-114535426-gh.circle-artifacts.com/0/home/circleci/docs/_preview/digger/latest/installation/digger-install-intro.html > > > [2] https://docs.openshift.com/ > > Date: Fri, 15 Dec 2017 13:56:57 +0000 > From: Laura Fitzgerald > To: AeroGear Developer Mailing List > , > feedhenry-dev at redhat.com > Subject: Re: [feedhenry-dev] Suggestion/Discussion - Removal of > AeroGear.org Production Branch > Message-ID: > > > Content-Type: text/plain; charset="utf-8" > > Hi all, > > I had sent this email re improving the way that we pubishaerogear.org . > Some may have seen it and replied but as there is some problems with > aerogear-dev mailing and there has been some further discussions I wanted > to reopen a conversation re Aerogear.org. > > With the move to the aerogear org there has been some conversation aroung > an overhaul of theaerogear.org website. > > It was also suggested that we could go with a brand new site rather than > rejigging the old site. > > I'm thinking that it would be worth having a discussion around how we would > go about this. > > If anyone has particular interest in this and/or experience with the old > site and existing tech and wants to open a proposal/discussion re tech > stack, design, content etc I think it would be suitable to to do that via > the proposals repo [1] or via some discussion here. > > I've been involved in adding some content recently with the Aerogear Digger > Project and my vote would be for creating something new and shiny!!! > > Wdy guys t? > > [1]https://github.com/aerogear/proposals > > > On Wed, Dec 6, 2017 at 11:07 AM, Laura Fitzgerald > wrote: > >> Hi all, >> >> I have recently gone through the process of publishing documentation for >> AeroGear Digger toaerogear.org . >> >> The process for adding docs for digger was as follows: >> >> - Make changes on Feature Branch over a period of time. >> - At some point merge lots of commits (difficult to review) from Feature >> Branch to master. >> - This publishes tostaging.aerogear.org (build needs to be manually >> triggered in Jenkins) >> - At some point merge master (again with lots of commits) to production >> branch >> - This publishes toaerogear.org (build needs to be manually triggered) >> >> Out of this we attempted to improve the process by adding development >> steps to the README [1] outlining that >> -> each change should be verified on it's own -> merged to master -> and >> then merged to production >> removing the wait time and merges which involved lots of commits and >> changes. >> >> *I think there are a few things we can do to make this better. (simpler)* >> >> *1) How?* >> >> Remove the production branch (and related steps) altogether. >> >> *Why?* >> >> - All this documentation is done in the open. >> - All branches are visible to all users/developers. >> -staging.aerogear.org is not private so I don't see that we gain >> something by having this step. >> - Changes can be verified locally by building the website using the steps >> in the README [2] before being merged to master. >> >> *2) How?* >> Automate the publishing of the site >> >> *Why?* >> Right now the building of the site has to be triggered manually via a >> Jenkins instance on cloudbees. If we remove production and enforce that all >> changes are fully verified before being merged to master then we can >> automate that any new changes are published immediately once merged to >> master. >> >> *3) How?* >> Add some sort of versioning to the documentation. This could be in the >> form of tagging the repo once we have a release of a product. >> >> *Why?* >> If we are always publishing docs once a change is made to the product then >> we should version the documentation so we know which version of the docs >> matches older versions of the product. >> >> ~~~~~~~~~~~ >> >> I'm really interested in some feedback on this. Let me know what you >> think. Is there a better/simpler way to do it than I suggested? >> >> [1]https://github.com/aerogear/aerogear.org/blob/ >> >> master/README.md#development-steps >> [2]https://github.com/aerogear/aerogear.org/blob/ >> >> master/README.md#building >> -- >> >> LAURA FITZGERALD >> >> Red Hat Mobile >> >> Communications House, Cork Road >> >> Waterford City, Ireland X91NY33 >> >> lfitzger at redhat.com IM: lfitzgerald >> >> >> > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > > > > > -- > > WOJCIECH TROCKI > > Red Hat Mobile > > IM: wtrocki > > > > > _______________________________________________ > feedhenry-dev mailing list > feedhenry-dev at redhat.com > https://www.redhat.com/mailman/listinfo/feedhenry-dev > > > > > > -- > David Martin > Red Hat Mobile > Twitter: @irldavem > IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2017-12-19 at 9.28.29 AM.png Type: image/png Size: 300684 bytes Desc: not available URL: From davmarti at redhat.com Tue Dec 19 12:49:18 2017 From: davmarti at redhat.com (David Martin) Date: Tue, 19 Dec 2017 12:49:18 +0000 Subject: [feedhenry-dev] Suggestion/Discussion - Removal of AeroGear.org Production Branch In-Reply-To: References: <8bdb3c64-3b82-0b77-38aa-93ee836954df@redhat.com> Message-ID: On 19 December 2017 at 12:37, Paul Wright wrote: > Hi, > On 12/19/2017 09:46 AM, David Martin wrote: > > I like the idea of a custom landing page, and using asciibinder thereafter > for all docs. > The landing page would initially function as a gateway to the upstream > docs, and any other upstream content (e.g. contributing guide) > Adding downstream or other version of docs could come later. > > @Paul, @Laura What would be involved in converting the existing Aerogear > docs into asciidoc and getting them working with asciibinder? > > Good news! Digger doc is already in asciidoc (altho some work required, eg > file suffix, include syntax is non-standard) > re. Push, I'm thinking this is the major piece? https://aerogear.org/docs/ > unifiedpush/ups_userguide/index/ > > I'll convert that to asciidoc as a first step in this journey > > It would make sense to leave behind docs for anything deprecated or no > longer maintained. > > How would that work? a link to 'Old site'? > I'm not sure, but I would love to avoid a scenario where 2 sites exist. To give an example of why I don't like that, take Keycloak Docs. I did a google search for Keycloak Identiy Brokering and get a link to https://keycloak.gitbooks.io/documentation/server_admin/topics/identity-broker.html However, thats the old site, which just gives a link to the new site. What makes it worse is the link to the new site brings me to a landing page where I need to try find what I'm looking for again. http://www.keycloak.org/documentation.html. Awful user experience. > > > > Updating any docs (e.g. UPS) could be a task for after the initial > 'getting things working with asciibinder'. > Similarly, moving Sync docs could be a task after the initial work. > > > On 19 December 2017 at 09:34, Wojciech Trocki wrote: > >> +1 for kicking out some investigations. >> Let me know if you need something specific. >> I see that most of the JBoos products now using ascidocs based >> documentation. >> >> For example: >> http://www.keycloak.org/docs/latest/getting_started/index.html >> https://docs.jboss.org/jbpm/release/7.4.1.Final/jbpm-docs/html_single >> >> >> > However I'm not sure if this means revamping aerogear.org or the >> introduction of a new site docs.aerogear.org ? >> >> Aerogear is project aggregator website so aproach will need to be >> different than when building webpage for single project. >> IMHO best is to refresh aerogear webpage layout to support project >> subpages. For example >> >> aerogear.org/sync >> aerogear.org/digger >> >> Example layout: >> >> [image: Inline image 1] >> Then each of this subpages can have general information, links to >> documentation, supported versions etc. >> This aproach is really common for open source projects aggregators. >> >> >> On Mon, Dec 18, 2017 at 8:04 PM, Paul Wright wrote: >> >>> Hi Laura, All, >>> I'd like to follow up about the suggestion of a new site, thinking >>> specifically about: >>> * much of the existing content is out of date >>> * there is a lot of 'formerly feedhenry) material to be published next >>> year (eg mcp, sync) >>> * the rendering toolchain is sub-optimal (in my POV) >>> * big changes are happening anyway (now is the opportunity) >>> >>> However I'm not sure if this means revamping aerogear.org or the >>> introduction of a new site docs.aerogear.org ? >>> So, let me propose this, which is what I'd like to see: >>> >>> * Versioned docs for each component >>> * A doc set for combining a set of components into a release >>> * An asciidoc-first approach to the docs (altho I'd like to see markdown >>> still supported for blogs/etc) >>> >>> With this in mind, I'm playing with asciibinder, for example, see the >>> digger docs [1], this has the advantage: >>> >>> * it's what OpenShift uses >>> * it's geared towards complex doc sets >>> * it's geared to multiple version doc sets >>> * it's lightweight and gathering some momentum (eg fedora are now using >>> it) >>> >>> Maybe it's used for everything but the home page as per OS [2] >>> >>> Or maybe the existing aerogear.org lives on, and users only hit the >>> asciibinder html at a lower level? >>> >>> WDYT? >>> >>> thanks, >>> Paul >>> >>> >>> [1] https://5-114535426-gh.circle-artifacts.com/0/home/circleci/ >>> docs/_preview/digger/latest/installation/digger-install-intro.html >>> >>> [2] https://docs.openshift.com/ >>> >>> Date: Fri, 15 Dec 2017 13:56:57 +0000 >>> From: Laura Fitzgerald >>> To: AeroGear Developer Mailing List , >>> feedhenry-dev at redhat.com >>> Subject: Re: [feedhenry-dev] Suggestion/Discussion - Removal of >>> AeroGear.org Production Branch >>> Message-ID: >>> >>> Content-Type: text/plain; charset="utf-8" >>> >>> Hi all, >>> >>> I had sent this email re improving the way that we pubish aerogear.org. >>> Some may have seen it and replied but as there is some problems with >>> aerogear-dev mailing and there has been some further discussions I wanted >>> to reopen a conversation re Aerogear.org. >>> >>> With the move to the aerogear org there has been some conversation aroung >>> an overhaul of the aerogear.org website. >>> >>> It was also suggested that we could go with a brand new site rather than >>> rejigging the old site. >>> >>> I'm thinking that it would be worth having a discussion around how we would >>> go about this. >>> >>> If anyone has particular interest in this and/or experience with the old >>> site and existing tech and wants to open a proposal/discussion re tech >>> stack, design, content etc I think it would be suitable to to do that via >>> the proposals repo [1] or via some discussion here. >>> >>> I've been involved in adding some content recently with the Aerogear Digger >>> Project and my vote would be for creating something new and shiny!!! >>> >>> Wdy guys t? >>> >>> [1] https://github.com/aerogear/proposals >>> >>> On Wed, Dec 6, 2017 at 11:07 AM, Laura Fitzgerald >>> wrote: >>> >>> >>> Hi all, >>> >>> I have recently gone through the process of publishing documentation for >>> AeroGear Digger to aerogear.org. >>> >>> The process for adding docs for digger was as follows: >>> >>> - Make changes on Feature Branch over a period of time. >>> - At some point merge lots of commits (difficult to review) from Feature >>> Branch to master. >>> - This publishes to staging.aerogear.org (build needs to be manually >>> triggered in Jenkins) >>> - At some point merge master (again with lots of commits) to production >>> branch >>> - This publishes to aerogear.org (build needs to be manually triggered) >>> >>> Out of this we attempted to improve the process by adding development >>> steps to the README [1] outlining that >>> -> each change should be verified on it's own -> merged to master -> and >>> then merged to production >>> removing the wait time and merges which involved lots of commits and >>> changes. >>> >>> *I think there are a few things we can do to make this better. (simpler)* >>> >>> *1) How?* >>> >>> Remove the production branch (and related steps) altogether. >>> >>> *Why?* >>> >>> - All this documentation is done in the open. >>> - All branches are visible to all users/developers. >>> - staging.aerogear.org is not private so I don't see that we gain >>> something by having this step. >>> - Changes can be verified locally by building the website using the steps >>> in the README [2] before being merged to master. >>> >>> *2) How?* >>> Automate the publishing of the site >>> >>> *Why?* >>> Right now the building of the site has to be triggered manually via a >>> Jenkins instance on cloudbees. If we remove production and enforce that all >>> changes are fully verified before being merged to master then we can >>> automate that any new changes are published immediately once merged to >>> master. >>> >>> *3) How?* >>> Add some sort of versioning to the documentation. This could be in the >>> form of tagging the repo once we have a release of a product. >>> >>> *Why?* >>> If we are always publishing docs once a change is made to the product then >>> we should version the documentation so we know which version of the docs >>> matches older versions of the product. >>> >>> ~~~~~~~~~~~ >>> >>> I'm really interested in some feedback on this. Let me know what you >>> think. Is there a better/simpler way to do it than I suggested? >>> >>> [1] https://github.com/aerogear/aerogear.org/blob/ >>> master/README.md#development-steps >>> [2] https://github.com/aerogear/aerogear.org/blob/ >>> master/README.md#building >>> -- >>> >>> LAURA FITZGERALD >>> >>> Red Hat Mobile >>> >>> Communications House, Cork Road >>> >>> Waterford City, Ireland X91NY33 >>> lfitzger at redhat.com IM: lfitzgerald >>> >>> >>> _______________________________________________ >>> feedhenry-dev mailing list >>> feedhenry-dev at redhat.com >>> https://www.redhat.com/mailman/listinfo/feedhenry-dev >>> >>> >> >> >> -- >> >> WOJCIECH TROCKI >> >> Red Hat Mobile >> >> IM: wtrocki >> >> >> _______________________________________________ >> 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) > > > -- David Martin Red Hat Mobile Twitter: @irldavem IRC: @irldavem (feedhenry, mobile-internal) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2017-12-19 at 9.28.29 AM.png Type: image/png Size: 300684 bytes Desc: not available URL: From pwright at redhat.com Tue Dec 19 21:20:34 2017 From: pwright at redhat.com (Paul Wright) Date: Tue, 19 Dec 2017 21:20:34 +0000 Subject: [feedhenry-dev] Are we there yet? Message-ID: <0a7ca92a-0094-ef40-56ff-7cd3a8f9e01e@redhat.com> As a Red Hat middleware Developer, I want to know more about Mobile. 1. https://developers.redhat.com/projects/#!filter-products=middleware a) *Included in* pull down lists all the downstream projects related to open source but doesn't list RHMAP (or Mobile.next) b) The top three just link to the associated web site, but all the others link to *Learn more* and *Download*. c) The*Learn more *link for AeroGear displays the following: > > Aerogear > > Open Source Libraries for Mobile Connectivity > > * Docs:Documentation > * Community:aerogear.org/community > * Mailing List:lists.jboss.org/mailman/listinfo/aerogear-dev > > * Chat:webchat.freenode.net/?channels=aerogear > > * JIRA:issues.jboss.org/browse/AEROGEAR > > * Source:https://github.com/aerogear > * Github:github.com/aerogear > * Build:aerogear.ci.cloudbees.com/ > I'm planning on keeping this, except for removing that last entry for Build, do we have a replacement link? d) The *Download* link does not offer a positive ux. -- Paul Wright Mobile Docs (github: finp) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwessend at redhat.com Wed Dec 20 10:25:02 2017 From: mwessend at redhat.com (Matthias Wessendorf) Date: Wed, 20 Dec 2017 11:25:02 +0100 Subject: [feedhenry-dev] Mobile Service in Openshift Message-ID: we have now colored images for the services: https://twitter.com/mwessendorf/status/943426656546574336 :-) -- Project lead AeroGear.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgallaso at redhat.com Wed Dec 20 11:45:48 2017 From: jgallaso at redhat.com (Jose Miguel Gallas Olmedo) Date: Wed, 20 Dec 2017 12:45:48 +0100 Subject: [feedhenry-dev] [aerogear-dev] Service Catalog Intro video In-Reply-To: References: Message-ID: Kudos for the guy's sweatshirt :) JOSE MIGUEL GALLAS OLMEDO ASSOCIATE QE, mobile Red Hat M: +34618488633 On 13 December 2017 at 11:34, Wei Li wrote: > Thanks for sharing Dave. Great video, explains service catalog very well > from a high level. > > On Wed, Dec 13, 2017 at 9:50 AM, David Martin wrote: > >> This is a great intro for anyone not familiar with the kubernetes service >> catalog & brokers. >> >> https://www.youtube.com/watch?v=0aLqc-o256w >> >> The service catalog calls out to a broker (e.g. the Ansible Service >> Broker) to provision things. >> >> The Ansible Service Broker kicks off an Ansible Playbook Bundle (e.g. >> unifiedpush-apb, fh-sync-server-apb) to actually do the provisioning steps. >> >> >> -- >> 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 >> >> > > > -- > > WEI LI > > SENIOR SOFTWARE ENGINEER > > Red Hat Mobile > > weil at redhat.com M: +353862393272 > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aliok at redhat.com Thu Dec 21 10:39:56 2017 From: aliok at redhat.com (Ali Ok) Date: Thu, 21 Dec 2017 13:39:56 +0300 Subject: [feedhenry-dev] GSOC 2018 - 2 AeroGear Digger ideas Message-ID: Hi, We have 2 ideas for GSoC 2018 with AeroGear Digger. - AeroGear Digger - Xamarin support - AeroGear Digger - CI/CD workflows on AeroGear Digger with advanced testing cases https://developer.jboss.org/wiki/GSoC2018Ideas Any feedback is appreciated. Or, let us know if you're interested as students :) Cheers, Ali -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgallaso at redhat.com Thu Dec 21 11:19:30 2017 From: jgallaso at redhat.com (Jose Miguel Gallas Olmedo) Date: Thu, 21 Dec 2017 12:19:30 +0100 Subject: [feedhenry-dev] [aerogear-dev] When to merge a proposal In-Reply-To: References: Message-ID: At least 2 sounds about right JOSE MIGUEL GALLAS OLMEDO ASSOCIATE QE, mobile Red Hat M: +34618488633 On 15 December 2017 at 11:14, David Martin wrote: > +1 > > > > On 15 December 2017 at 10:06, John Frizelle wrote: > >> LGTM :-) >> >> -- >> John Frizelle >> Chief Architect, Red Hat Mobile >> Consulting Engineer >> >> mobile: *+353 87 290 1644 * >> twitter:* @johnfriz* >> skype: *john_frizelle* >> mail: *jfrizell at redhat.com * >> >> >> >> >> On 15 December 2017 at 10:05, Craig Brookes wrote: >> >>> I think we should use a common strategy in the Open Source world, that >>> in general you need at least two LGTM thumbs up from bona fide reviewers >>> before being allowed to merge. >>> >>> Thoughts? >>> >>> -- >>> Craig Brookes >>> RHMAP >>> @maleck13 Github >>> >>> _______________________________________________ >>> 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) > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 11472 bytes Desc: not available URL: From jgallaso at redhat.com Thu Dec 21 13:22:16 2017 From: jgallaso at redhat.com (Jose Miguel Gallas Olmedo) Date: Thu, 21 Dec 2017 14:22:16 +0100 Subject: [feedhenry-dev] [aerogear-dev] Deprecate AeroGear auth libraries In-Reply-To: References: Message-ID: +1 JOSE MIGUEL GALLAS OLMEDO ASSOCIATE QE, mobile Red Hat M: +34618488633 On 18 December 2017 at 16:17, Matthias Wessendorf wrote: > +1 > > On Mon, Dec 18, 2017 at 3:37 PM, Daniel Passos wrote: > >> Hi, >> >> Today we have libraries to handle Auth stuff for HTTP Basic and HTTP >> Digest, this libraries is no longer maintained for a long time and I think >> no one is using this kind of Auth anymore. Should we archive it and move to >> the aerogear-attic[1] >> >> [1] https://github.com/aerogear-attic >> >> -- >> -- Passos >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > Project lead AeroGear.org > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgallaso at redhat.com Thu Dec 21 13:23:00 2017 From: jgallaso at redhat.com (Jose Miguel Gallas Olmedo) Date: Thu, 21 Dec 2017 14:23:00 +0100 Subject: [feedhenry-dev] [aerogear-dev] Deprecated aerogear-cordova-geo In-Reply-To: References: Message-ID: I agree with Matthias JOSE MIGUEL GALLAS OLMEDO ASSOCIATE QE, mobile Red Hat M: +34618488633 On 18 December 2017 at 16:18, Matthias Wessendorf wrote: > yeah, I'm +1 on that > > Even if we spin up something new around GEO, we can still borrow/leverage > code from here - if really needed > > > > On Mon, Dec 18, 2017 at 3:38 PM, Daniel Passos wrote: > >> Hi, >> >> Should we deprecated aerogear-cordova-geo[1]? >> >> Cordova is the only one has the Geo library and the last commit on this >> library was in Sep 7, 2015 >> >> [1] https://github.com/aerogear/aerogear-cordova-geo >> >> -- >> -- Passos >> >> _______________________________________________ >> feedhenry-dev mailing list >> feedhenry-dev at redhat.com >> https://www.redhat.com/mailman/listinfo/feedhenry-dev >> >> > > > -- > Project lead AeroGear.org > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wtrocki at redhat.com Sat Dec 23 15:30:39 2017 From: wtrocki at redhat.com (Wojciech Trocki) Date: Sat, 23 Dec 2017 15:30:39 +0000 Subject: [feedhenry-dev] AWS AppSync (Data Sync built aroundGraphQL) In-Reply-To: References: Message-ID: *Moving to mobile-dev to avoid spamming* @Evan - Thank you so much for sharing this! I reviewed AWS AppSync documentation to learn more about approaches they use. Graphql for transport and comprehensive sdks provide really good base for sync services. AppSync has many good patterns and solutions that we can learn from and apply to our domain. Google Firebase already has answer to AWS AppSync called Cloud Firestore which is also in beta stage (with public access) https://venturebeat.com/2017/10/03/googles-firebase-releases -cloud-firestore-a-nosql-database-for-app-developers Both services have common limitations - no open source code and possibility to run server on your own. Apart from AWS and Firebase we have many open source players without that limitations: - https://realm.io/blog/introducing-realm-mobile-platform - https://deepstream.io - https://telepat.io/platform.html - https://www.apollographql.com - https://www.graph.cool I'm in process of comparing architectures (already seeing multiple common elements). This will allow us to get some overview of best patterns for building and using API's, SDK's, transports (websockets etc.) used in industry. [image: Inline image 1] After 3 weeks I finally got approval from AWS for access to AWS AppSync beta. Beta is not open to the public so if you guys want to try this let me know. Regards On Wed, Nov 29, 2017 at 9:08 AM, Karel Piwko wrote: > I know that Serhii has been experimenting with GraphQL as well. He might > have some feedback to share. > > Cheers, > > Karel > > On 29 November 2017 at 09:58, Craig Brookes wrote: > >> Interesting. Graphql is an interesting choice and probably something that >> we should look into for our sync service, it seems very useful for mobile >> devices, allowing for querying and only returning small subsets of the data >> >> On Tue, Nov 28, 2017 at 10:52 PM, Evan Shortiss >> wrote: >> >>> Hi folks, >>> >>> Interesting news from AWS today on the mobile front. They announced a >>> Data Sync product named AppSync[1] >>> >>> It's pretty interesting that they've bet on GraphQL as the API layer. >>> >>> [1] - https://aws.amazon.com/blogs/aws/introducing-amazon-appsync/ >>> >>> -- >>> >>> EVAN SHORTISS >>> >>> MOBILE DEVELOPER >>> >>> Red Hat NA >>> >>> Los Angeles >>> >>> evan.shortiss at redhat.com M: +1-781-354-2834 IM: @evanshortiss >>> >>> TRIED. TESTED. TRUSTED. >>> @redhatnews Red Hat >>> Red Hat >>> >>> >> >> >> >> -- >> Craig Brookes >> RHMAP >> @maleck13 Github >> > > > > -- > > KAREL PIWKO > > MANAGER, MOBILE QE > > Red Hat Czech Republic > > Purky?ova 647/111 > > 612 00 Brno, Czech Republic > > kpiwko at redhat.com IM: kpiwko > > TRIED. TESTED. TRUSTED. > @redhatway @redhatinc > @redhatsnaps > > -- WOJCIECH TROCKI Red Hat Mobile IM: wtrocki -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 799109 bytes Desc: not available URL: