[feedhenry-dev] Upstream Community Documentation

David Martin davmarti at redhat.com
Thu Nov 30 09:49:11 UTC 2017


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 at redhat.com> wrote:

> Ali Ok <aliok at 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 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: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20171130/163074fe/attachment.htm>


More information about the feedhenry-dev mailing list