+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 <davmarti@redhat.com> 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 <gryan@redhat.com> wrote:
Ali Ok <aliok@redhat.com> 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@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@redhat.com
https://www.redhat.com/mailman/listinfo/feedhenry-dev




--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

weil@redhat.com    M: +353862393272