Re: feedhenry-dev Digest, Vol 16, Issue 60

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

Re: feedhenry-dev Digest, Vol 16, Issue 60

Craig Brookes
I think what you have outlined is great for our development releases, Matthias. If we haven't already we should update the doc.

On the single repo, yes no git submodules, but I am big fan of it being in a single repo allow visibility for everything mcp that it happening and then syncing to separate repos for releases but as mentioned this is something we can get together and discuss as the f2f

On Thu, Oct 26, 2017 at 8:52 AM, <[hidden email]> wrote:
Send feedhenry-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.redhat.com/mailman/listinfo/feedhenry-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of feedhenry-dev digest..."


Today's Topics:

   1. RFC: MCP-standalone Release Process (Matthias Wessendorf)
   2. Re: RFC: MCP-standalone Release Process (Phil Brookes)
   3. Re: RFC: MCP-standalone Release Process (Matthias Wessendorf)


----------------------------------------------------------------------

Message: 1
Date: Wed, 25 Oct 2017 20:20:30 +0200
From: Matthias Wessendorf <[hidden email]>
To: [hidden email]
Subject: [feedhenry-dev] RFC: MCP-standalone Release Process
Message-ID:
        <CAKUFdH1rt9y6Sirua0UxcsW6Ux+gO+xfP311=[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hi,

as a follow up on [1], here are some thoughts on the MCP release itself.

The raw process is described here:
https://github.com/matzew/mcp-standalone/blob/Release_Process/docs/Release.md#mcp-release

The first part is trivial (but not complete), we simply create a TAGGED
(versioned) image, and push it to docker. Afterwards the mcp-standalone in
dockerhub is updated.

What's missing here is creation of a canonical TAG in git, more later;

Now, the (three) dependent APBs of the MCP also need to be released. This
requires a bit of manual steps, as described here:
https://github.com/matzew/mcp-standalone/blob/Release_Process/docs/Release.md#mcp-included-apbs

1) manual modify the openshift template (which is included in the dependent
APBs)
2) creating image tags and pushing all to dockerhub (-> make apbs )


In 2) we also modify code, by copying the template over, for that I've
added a "release" commit in the Makefile target:
https://github.com/matzew/mcp-standalone/commit/8d693cc6b2d58d9a2d83e33ea6cf9e31ce8bcac5

But we still have a locally modified file on the disk (the original
openshift template). This is bad.
The changes to the template must be committed before we can actually move
on. To enforce that, I've added the following to the "make apbs" target:
https://github.com/feedhenry/mcp-standalone/commit/260fd86868e7d12fb33197bf1ca9672a2f7d4b1a#commitcomment-25186889

if there are not committed files, the "make apbs" fails- this is inspired
by the awesome ;-) Maven Release Plugin.

As the last step, after the different pushes to dockerhub (mcp-standalone
and its dependent APBs), we must create a release tag in git, and push it.

Only with these "rules" (e.g. no locally modified files, and proper release
tags, we end up having both in sync dockerhub images, and the matching TAG
in git)

I think these new rules help to get a more solid release, and with a bit of
work can be applied by some "release script"

But before hacking too much, I am generally interested in feedback on these
already committed changes.

Thanks!
Matthias


[1] https://www.redhat.com/archives/feedhenry-dev/2017-October/msg00114.html


--
Project lead AeroGear.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.redhat.com/archives/feedhenry-dev/attachments/20171025/68d2a0d3/attachment.html>

------------------------------

Message: 2
Date: Thu, 26 Oct 2017 08:43:13 +0100
From: Phil Brookes <[hidden email]>
To: Matthias Wessendorf <[hidden email]>
Cc: [hidden email]
Subject: Re: [feedhenry-dev] RFC: MCP-standalone Release Process
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hey Matthias,

Now, the (three) dependent APBs of the MCP also need to be released. This
> requires a bit of manual steps, as described here:
> https://github.com/matzew/mcp-standalone/blob/Release_
> Process/docs/Release.md#mcp-included-apbs
>
> 1) manual modify the openshift template (which is included in the
> dependent APBs)
> 2) creating image tags and pushing all to dockerhub (-> make apbs )
>

If the APBs that are currently included in the mcp-standalone repo were in
their own separate repos (just like keycloak, 3scale, etc are currently)
would that remove the requirement for these manual steps?
? I think it would be superior if we could have a standard workflow that
all APBs follow, rather than some APBs working one way and some working
another and requiring developers to remember which is which.


Regards,

Phil.?




On Wed, Oct 25, 2017 at 7:20 PM, Matthias Wessendorf <[hidden email]>
wrote:

> Hi,
>
> as a follow up on [1], here are some thoughts on the MCP release itself.
>
> The raw process is described here:
> https://github.com/matzew/mcp-standalone/blob/Release_
> Process/docs/Release.md#mcp-release
>
> The first part is trivial (but not complete), we simply create a TAGGED
> (versioned) image, and push it to docker. Afterwards the mcp-standalone in
> dockerhub is updated.
>
> What's missing here is creation of a canonical TAG in git, more later;
>
> Now, the (three) dependent APBs of the MCP also need to be released. This
> requires a bit of manual steps, as described here:
> https://github.com/matzew/mcp-standalone/blob/Release_
> Process/docs/Release.md#mcp-included-apbs
>
> 1) manual modify the openshift template (which is included in the
> dependent APBs)
> 2) creating image tags and pushing all to dockerhub (-> make apbs )
>
>
> In 2) we also modify code, by copying the template over, for that I've
> added a "release" commit in the Makefile target:
> https://github.com/matzew/mcp-standalone/commit/
> 8d693cc6b2d58d9a2d83e33ea6cf9e31ce8bcac5
>
> But we still have a locally modified file on the disk (the original
> openshift template). This is bad.
> The changes to the template must be committed before we can actually move
> on. To enforce that, I've added the following to the "make apbs" target:
> https://github.com/feedhenry/mcp-standalone/commit/
> 260fd86868e7d12fb33197bf1ca9672a2f7d4b1a#commitcomment-25186889
>
> if there are not committed files, the "make apbs" fails- this is inspired
> by the awesome ;-) Maven Release Plugin.
>
> As the last step, after the different pushes to dockerhub (mcp-standalone
> and its dependent APBs), we must create a release tag in git, and push it.
>
> Only with these "rules" (e.g. no locally modified files, and proper
> release tags, we end up having both in sync dockerhub images, and the
> matching TAG in git)
>
> I think these new rules help to get a more solid release, and with a bit
> of work can be applied by some "release script"
>
> But before hacking too much, I am generally interested in feedback on
> these already committed changes.
>
> Thanks!
> Matthias
>
>
> [1] https://www.redhat.com/archives/feedhenry-dev/2017-
> October/msg00114.html
>
>
> --
> Project lead AeroGear.org
>
> _______________________________________________
> feedhenry-dev mailing list
> [hidden email]
> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.redhat.com/archives/feedhenry-dev/attachments/20171026/6dfa87dc/attachment.html>

------------------------------

Message: 3
Date: Thu, 26 Oct 2017 09:52:05 +0200
From: Matthias Wessendorf <[hidden email]>
To: Phil Brookes <[hidden email]>
Cc: [hidden email]
Subject: Re: [feedhenry-dev] RFC: MCP-standalone Release Process
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

On Thu, Oct 26, 2017 at 9:43 AM, Phil Brookes <[hidden email]> wrote:

> Hey Matthias,
>
> Now, the (three) dependent APBs of the MCP also need to be released. This
>> requires a bit of manual steps, as described here:
>> https://github.com/matzew/mcp-standalone/blob/Release_Proces
>> s/docs/Release.md#mcp-included-apbs
>>
>> 1) manual modify the openshift template (which is included in the
>> dependent APBs)
>> 2) creating image tags and pushing all to dockerhub (-> make apbs )
>>
>
> If the APBs that are currently included in the mcp-standalone repo were in
> their own separate repos (just like keycloak, 3scale, etc are currently)
> would that remove the requirement for these manual steps?
>

no - these three guys (android, ios, cordova) are special ABPs :-) They are
MCPs, and they need the updated template.
With a separated repo, they would each need a PR to get the updated version.



> ? I think it would be superior if we could have a standard workflow that
> all APBs follow, rather than some APBs working one way and some working
> another and requiring developers to remember which is which.
>

So yeah, I think these three are a bit special :)

BTW. yesterday on IRC Craig suggested at our F2F in a couple of weeks we
all sit down and discuss a good approach for this. He mentione kubernetes,
where different things are in their own repos, but sync'd to the main one
(no damn gitsubmodules)



>
>
> Regards,
>
> Phil.?
>
>
>
>
> On Wed, Oct 25, 2017 at 7:20 PM, Matthias Wessendorf <[hidden email]>
> wrote:
>
>> Hi,
>>
>> as a follow up on [1], here are some thoughts on the MCP release itself.
>>
>> The raw process is described here:
>> https://github.com/matzew/mcp-standalone/blob/Release_Proces
>> s/docs/Release.md#mcp-release
>>
>> The first part is trivial (but not complete), we simply create a TAGGED
>> (versioned) image, and push it to docker. Afterwards the mcp-standalone in
>> dockerhub is updated.
>>
>> What's missing here is creation of a canonical TAG in git, more later;
>>
>> Now, the (three) dependent APBs of the MCP also need to be released. This
>> requires a bit of manual steps, as described here:
>> https://github.com/matzew/mcp-standalone/blob/Release_Proces
>> s/docs/Release.md#mcp-included-apbs
>>
>> 1) manual modify the openshift template (which is included in the
>> dependent APBs)
>> 2) creating image tags and pushing all to dockerhub (-> make apbs )
>>
>>
>> In 2) we also modify code, by copying the template over, for that I've
>> added a "release" commit in the Makefile target:
>> https://github.com/matzew/mcp-standalone/commit/8d693cc6b2d5
>> 8d9a2d83e33ea6cf9e31ce8bcac5
>>
>> But we still have a locally modified file on the disk (the original
>> openshift template). This is bad.
>> The changes to the template must be committed before we can actually move
>> on. To enforce that, I've added the following to the "make apbs" target:
>> https://github.com/feedhenry/mcp-standalone/commit/260fd8686
>> 8e7d12fb33197bf1ca9672a2f7d4b1a#commitcomment-25186889
>>
>> if there are not committed files, the "make apbs" fails- this is inspired
>> by the awesome ;-) Maven Release Plugin.
>>
>> As the last step, after the different pushes to dockerhub (mcp-standalone
>> and its dependent APBs), we must create a release tag in git, and push it.
>>
>> Only with these "rules" (e.g. no locally modified files, and proper
>> release tags, we end up having both in sync dockerhub images, and the
>> matching TAG in git)
>>
>> I think these new rules help to get a more solid release, and with a bit
>> of work can be applied by some "release script"
>>
>> But before hacking too much, I am generally interested in feedback on
>> these already committed changes.
>>
>> Thanks!
>> Matthias
>>
>>
>> [1] https://www.redhat.com/archives/feedhenry-dev/2017-Octob
>> er/msg00114.html
>>
>>
>> --
>> Project lead AeroGear.org
>>
>> _______________________________________________
>> feedhenry-dev mailing list
>> [hidden email]
>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>
>>
>


--
Project lead AeroGear.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.redhat.com/archives/feedhenry-dev/attachments/20171026/37a80476/attachment.html>

------------------------------

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


End of feedhenry-dev Digest, Vol 16, Issue 60
*********************************************



--
Craig Brookes
RHMAP 
@maleck13 Github

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

Re: feedhenry-dev Digest, Vol 16, Issue 60

Matthias Wessendorf


On Thu, Oct 26, 2017 at 9:56 AM, Craig Brookes <[hidden email]> wrote:
I think what you have outlined is great for our development releases, Matthias. If we haven't already we should update the doc.

Ok, cool - 

I will weave that into the doc(s), and send PRs
 

On the single repo, yes no git submodules, but I am big fan of it being in a single repo allow visibility for everything mcp that it happening and then syncing to separate repos for releases but as mentioned this is something we can get together and discuss as the f2f

On Thu, Oct 26, 2017 at 8:52 AM, <[hidden email]> wrote:
Send feedhenry-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.redhat.com/mailman/listinfo/feedhenry-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of feedhenry-dev digest..."


Today's Topics:

   1. RFC: MCP-standalone Release Process (Matthias Wessendorf)
   2. Re: RFC: MCP-standalone Release Process (Phil Brookes)
   3. Re: RFC: MCP-standalone Release Process (Matthias Wessendorf)


----------------------------------------------------------------------

Message: 1
Date: Wed, 25 Oct 2017 20:20:30 +0200
From: Matthias Wessendorf <[hidden email]>
To: [hidden email]
Subject: [feedhenry-dev] RFC: MCP-standalone Release Process
Message-ID:
        <CAKUFdH1rt9y6Sirua0UxcsW6Ux+gO+xfP311=[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hi,

as a follow up on [1], here are some thoughts on the MCP release itself.

The raw process is described here:
https://github.com/matzew/mcp-standalone/blob/Release_Process/docs/Release.md#mcp-release

The first part is trivial (but not complete), we simply create a TAGGED
(versioned) image, and push it to docker. Afterwards the mcp-standalone in
dockerhub is updated.

What's missing here is creation of a canonical TAG in git, more later;

Now, the (three) dependent APBs of the MCP also need to be released. This
requires a bit of manual steps, as described here:
https://github.com/matzew/mcp-standalone/blob/Release_Process/docs/Release.md#mcp-included-apbs

1) manual modify the openshift template (which is included in the dependent
APBs)
2) creating image tags and pushing all to dockerhub (-> make apbs )


In 2) we also modify code, by copying the template over, for that I've
added a "release" commit in the Makefile target:
https://github.com/matzew/mcp-standalone/commit/8d693cc6b2d58d9a2d83e33ea6cf9e31ce8bcac5

But we still have a locally modified file on the disk (the original
openshift template). This is bad.
The changes to the template must be committed before we can actually move
on. To enforce that, I've added the following to the "make apbs" target:
https://github.com/feedhenry/mcp-standalone/commit/260fd86868e7d12fb33197bf1ca9672a2f7d4b1a#commitcomment-25186889

if there are not committed files, the "make apbs" fails- this is inspired
by the awesome ;-) Maven Release Plugin.

As the last step, after the different pushes to dockerhub (mcp-standalone
and its dependent APBs), we must create a release tag in git, and push it.

Only with these "rules" (e.g. no locally modified files, and proper release
tags, we end up having both in sync dockerhub images, and the matching TAG
in git)

I think these new rules help to get a more solid release, and with a bit of
work can be applied by some "release script"

But before hacking too much, I am generally interested in feedback on these
already committed changes.

Thanks!
Matthias


[1] https://www.redhat.com/archives/feedhenry-dev/2017-October/msg00114.html


--
Project lead AeroGear.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.redhat.com/archives/feedhenry-dev/attachments/20171025/68d2a0d3/attachment.html>

------------------------------

Message: 2
Date: Thu, 26 Oct 2017 08:43:13 +0100
From: Phil Brookes <[hidden email]>
To: Matthias Wessendorf <[hidden email]>
Cc: [hidden email]
Subject: Re: [feedhenry-dev] RFC: MCP-standalone Release Process
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

Hey Matthias,

Now, the (three) dependent APBs of the MCP also need to be released. This
> requires a bit of manual steps, as described here:
> https://github.com/matzew/mcp-standalone/blob/Release_
> Process/docs/Release.md#mcp-included-apbs
>
> 1) manual modify the openshift template (which is included in the
> dependent APBs)
> 2) creating image tags and pushing all to dockerhub (-> make apbs )
>

If the APBs that are currently included in the mcp-standalone repo were in
their own separate repos (just like keycloak, 3scale, etc are currently)
would that remove the requirement for these manual steps?
? I think it would be superior if we could have a standard workflow that
all APBs follow, rather than some APBs working one way and some working
another and requiring developers to remember which is which.


Regards,

Phil.?




On Wed, Oct 25, 2017 at 7:20 PM, Matthias Wessendorf <[hidden email]>
wrote:

> Hi,
>
> as a follow up on [1], here are some thoughts on the MCP release itself.
>
> The raw process is described here:
> https://github.com/matzew/mcp-standalone/blob/Release_
> Process/docs/Release.md#mcp-release
>
> The first part is trivial (but not complete), we simply create a TAGGED
> (versioned) image, and push it to docker. Afterwards the mcp-standalone in
> dockerhub is updated.
>
> What's missing here is creation of a canonical TAG in git, more later;
>
> Now, the (three) dependent APBs of the MCP also need to be released. This
> requires a bit of manual steps, as described here:
> https://github.com/matzew/mcp-standalone/blob/Release_
> Process/docs/Release.md#mcp-included-apbs
>
> 1) manual modify the openshift template (which is included in the
> dependent APBs)
> 2) creating image tags and pushing all to dockerhub (-> make apbs )
>
>
> In 2) we also modify code, by copying the template over, for that I've
> added a "release" commit in the Makefile target:
> https://github.com/matzew/mcp-standalone/commit/
> 8d693cc6b2d58d9a2d83e33ea6cf9e31ce8bcac5
>
> But we still have a locally modified file on the disk (the original
> openshift template). This is bad.
> The changes to the template must be committed before we can actually move
> on. To enforce that, I've added the following to the "make apbs" target:
> https://github.com/feedhenry/mcp-standalone/commit/
> 260fd86868e7d12fb33197bf1ca9672a2f7d4b1a#commitcomment-25186889
>
> if there are not committed files, the "make apbs" fails- this is inspired
> by the awesome ;-) Maven Release Plugin.
>
> As the last step, after the different pushes to dockerhub (mcp-standalone
> and its dependent APBs), we must create a release tag in git, and push it.
>
> Only with these "rules" (e.g. no locally modified files, and proper
> release tags, we end up having both in sync dockerhub images, and the
> matching TAG in git)
>
> I think these new rules help to get a more solid release, and with a bit
> of work can be applied by some "release script"
>
> But before hacking too much, I am generally interested in feedback on
> these already committed changes.
>
> Thanks!
> Matthias
>
>
> [1] https://www.redhat.com/archives/feedhenry-dev/2017-
> October/msg00114.html
>
>
> --
> Project lead AeroGear.org
>
> _______________________________________________
> feedhenry-dev mailing list
> [hidden email]
> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.redhat.com/archives/feedhenry-dev/attachments/20171026/6dfa87dc/attachment.html>

------------------------------

Message: 3
Date: Thu, 26 Oct 2017 09:52:05 +0200
From: Matthias Wessendorf <[hidden email]>
To: Phil Brookes <[hidden email]>
Cc: [hidden email]
Subject: Re: [feedhenry-dev] RFC: MCP-standalone Release Process
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

On Thu, Oct 26, 2017 at 9:43 AM, Phil Brookes <[hidden email]> wrote:

> Hey Matthias,
>
> Now, the (three) dependent APBs of the MCP also need to be released. This
>> requires a bit of manual steps, as described here:
>> https://github.com/matzew/mcp-standalone/blob/Release_Proces
>> s/docs/Release.md#mcp-included-apbs
>>
>> 1) manual modify the openshift template (which is included in the
>> dependent APBs)
>> 2) creating image tags and pushing all to dockerhub (-> make apbs )
>>
>
> If the APBs that are currently included in the mcp-standalone repo were in
> their own separate repos (just like keycloak, 3scale, etc are currently)
> would that remove the requirement for these manual steps?
>

no - these three guys (android, ios, cordova) are special ABPs :-) They are
MCPs, and they need the updated template.
With a separated repo, they would each need a PR to get the updated version.



> ? I think it would be superior if we could have a standard workflow that
> all APBs follow, rather than some APBs working one way and some working
> another and requiring developers to remember which is which.
>

So yeah, I think these three are a bit special :)

BTW. yesterday on IRC Craig suggested at our F2F in a couple of weeks we
all sit down and discuss a good approach for this. He mentione kubernetes,
where different things are in their own repos, but sync'd to the main one
(no damn gitsubmodules)



>
>
> Regards,
>
> Phil.?
>
>
>
>
> On Wed, Oct 25, 2017 at 7:20 PM, Matthias Wessendorf <[hidden email]>
> wrote:
>
>> Hi,
>>
>> as a follow up on [1], here are some thoughts on the MCP release itself.
>>
>> The raw process is described here:
>> https://github.com/matzew/mcp-standalone/blob/Release_Proces
>> s/docs/Release.md#mcp-release
>>
>> The first part is trivial (but not complete), we simply create a TAGGED
>> (versioned) image, and push it to docker. Afterwards the mcp-standalone in
>> dockerhub is updated.
>>
>> What's missing here is creation of a canonical TAG in git, more later;
>>
>> Now, the (three) dependent APBs of the MCP also need to be released. This
>> requires a bit of manual steps, as described here:
>> https://github.com/matzew/mcp-standalone/blob/Release_Proces
>> s/docs/Release.md#mcp-included-apbs
>>
>> 1) manual modify the openshift template (which is included in the
>> dependent APBs)
>> 2) creating image tags and pushing all to dockerhub (-> make apbs )
>>
>>
>> In 2) we also modify code, by copying the template over, for that I've
>> added a "release" commit in the Makefile target:
>> https://github.com/matzew/mcp-standalone/commit/8d693cc6b2d5
>> 8d9a2d83e33ea6cf9e31ce8bcac5
>>
>> But we still have a locally modified file on the disk (the original
>> openshift template). This is bad.
>> The changes to the template must be committed before we can actually move
>> on. To enforce that, I've added the following to the "make apbs" target:
>> https://github.com/feedhenry/mcp-standalone/commit/260fd8686
>> 8e7d12fb33197bf1ca9672a2f7d4b1a#commitcomment-25186889
>>
>> if there are not committed files, the "make apbs" fails- this is inspired
>> by the awesome ;-) Maven Release Plugin.
>>
>> As the last step, after the different pushes to dockerhub (mcp-standalone
>> and its dependent APBs), we must create a release tag in git, and push it.
>>
>> Only with these "rules" (e.g. no locally modified files, and proper
>> release tags, we end up having both in sync dockerhub images, and the
>> matching TAG in git)
>>
>> I think these new rules help to get a more solid release, and with a bit
>> of work can be applied by some "release script"
>>
>> But before hacking too much, I am generally interested in feedback on
>> these already committed changes.
>>
>> Thanks!
>> Matthias
>>
>>
>> [1] https://www.redhat.com/archives/feedhenry-dev/2017-Octob
>> er/msg00114.html
>>
>>
>> --
>> Project lead AeroGear.org
>>
>> _______________________________________________
>> feedhenry-dev mailing list
>> [hidden email]
>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>
>>
>


--
Project lead AeroGear.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.redhat.com/archives/feedhenry-dev/attachments/20171026/37a80476/attachment.html>

------------------------------

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


End of feedhenry-dev Digest, Vol 16, Issue 60
*********************************************



--
Craig Brookes
RHMAP 
@maleck13 Github

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




--
Project lead AeroGear.org

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