RFC: MCP-standalone Release Process

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

RFC: MCP-standalone Release Process

Matthias Wessendorf
Hi,

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

The raw process is described here:

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:

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:

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:

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




--
Project lead AeroGear.org

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

Re: RFC: MCP-standalone Release Process

Phil Brookes
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:

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:

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:

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:

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:

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




--
Project lead AeroGear.org

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



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

Re: RFC: MCP-standalone Release Process

Matthias Wessendorf


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:

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:

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:

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:

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:

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




--
Project lead AeroGear.org

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





--
Project lead AeroGear.org

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

Re: RFC: MCP-standalone Release Process

David Martin
Those release steps sound logical to me.

It allows getting all apbs and the mcp version locked down so it can be tested and shared.

As its mostly scripted already, it's setting us up nicely for automating the entire upstream release process.

Having the various git repos tagged too is important to allow for downstream productisation, and  identifying when changes or bugs get introduced



On 26 October 2017 at 08:52, Matthias Wessendorf <[hidden email]> wrote:


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:

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:

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:

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:

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:

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




--
Project lead AeroGear.org

_______________________________________________
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




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

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

Re: RFC: MCP-standalone Release Process

Leigh Griffin
Just want to throw it out there that the XML Licenser is going to be a requirement here. It's not a painful step in the above that you described but it's a step nonetheless. So if our code is anything outside of Java (maven based) or Node.js we might need to consider building a tool to create the licensing information or reach out wider to find a team already in flight on it.

On Thu, Oct 26, 2017 at 11:23 AM, David Martin <[hidden email]> wrote:
Those release steps sound logical to me.

It allows getting all apbs and the mcp version locked down so it can be tested and shared.

As its mostly scripted already, it's setting us up nicely for automating the entire upstream release process.

Having the various git repos tagged too is important to allow for downstream productisation, and  identifying when changes or bugs get introduced



On 26 October 2017 at 08:52, Matthias Wessendorf <[hidden email]> wrote:


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:

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:

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:

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:

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:

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




--
Project lead AeroGear.org

_______________________________________________
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




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

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




--

LEIGH GRIFFIN

ENGINEERING MANAGER, MOBILE

Red Hat Ireland

Communications House, Cork Road

Waterford City, Ireland X91NY33

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


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

Re: RFC: MCP-standalone Release Process

Matthias Wessendorf
ok,

that's good info, I guess for MCP standalone developing this tool is a bit complex, but than I dont know enough about "package mgmt" w/ Go 






On Thu, Oct 26, 2017 at 4:18 PM, Leigh Griffin <[hidden email]> wrote:
Just want to throw it out there that the XML Licenser is going to be a requirement here. It's not a painful step in the above that you described but it's a step nonetheless. So if our code is anything outside of Java (maven based) or Node.js we might need to consider building a tool to create the licensing information or reach out wider to find a team already in flight on it.

On Thu, Oct 26, 2017 at 11:23 AM, David Martin <[hidden email]> wrote:
Those release steps sound logical to me.

It allows getting all apbs and the mcp version locked down so it can be tested and shared.

As its mostly scripted already, it's setting us up nicely for automating the entire upstream release process.

Having the various git repos tagged too is important to allow for downstream productisation, and  identifying when changes or bugs get introduced



On 26 October 2017 at 08:52, Matthias Wessendorf <[hidden email]> wrote:


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:

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:

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:

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:

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:

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




--
Project lead AeroGear.org

_______________________________________________
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




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

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




--

LEIGH GRIFFIN

ENGINEERING MANAGER, MOBILE

Red Hat Ireland

Communications House, Cork Road

Waterford City, Ireland X91NY33

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




--
Project lead AeroGear.org

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

Re: RFC: MCP-standalone Release Process

Matthias Wessendorf
on the APBs, that's likely simpler :) 

On Thu, Oct 26, 2017 at 4:31 PM, Matthias Wessendorf <[hidden email]> wrote:
ok,

that's good info, I guess for MCP standalone developing this tool is a bit complex, but than I dont know enough about "package mgmt" w/ Go 






On Thu, Oct 26, 2017 at 4:18 PM, Leigh Griffin <[hidden email]> wrote:
Just want to throw it out there that the XML Licenser is going to be a requirement here. It's not a painful step in the above that you described but it's a step nonetheless. So if our code is anything outside of Java (maven based) or Node.js we might need to consider building a tool to create the licensing information or reach out wider to find a team already in flight on it.

On Thu, Oct 26, 2017 at 11:23 AM, David Martin <[hidden email]> wrote:
Those release steps sound logical to me.

It allows getting all apbs and the mcp version locked down so it can be tested and shared.

As its mostly scripted already, it's setting us up nicely for automating the entire upstream release process.

Having the various git repos tagged too is important to allow for downstream productisation, and  identifying when changes or bugs get introduced



On 26 October 2017 at 08:52, Matthias Wessendorf <[hidden email]> wrote:


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:

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:

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:

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:

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:

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




--
Project lead AeroGear.org

_______________________________________________
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




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

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




--

LEIGH GRIFFIN

ENGINEERING MANAGER, MOBILE

Red Hat Ireland

Communications House, Cork Road

Waterford City, Ireland X91NY33

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




--
Project lead AeroGear.org



--
Project lead AeroGear.org

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

Re: RFC: MCP-standalone Release Process

Gerard Ryan
In reply to this post by Leigh Griffin
Leigh Griffin <[hidden email]> writes:

> Just want to throw it out there that the XML Licenser is going to be a
> requirement here. It's not a painful step in the above that you described
> but it's a step nonetheless. So if our code is anything outside of Java
> (maven based) or Node.js we might need to consider building a tool to
> create the licensing information or reach out wider to find a team already
> in flight on it.

Would that just be needed for the eventual Red Hat productization of it,
or is it also needed for the open source releases here?

In any case, I'd expect that other projects that Red Hat productizes
downstream, that are also Go projects, would also have this requirement,
right (e.g. OpenShift)? Whatever they're using, would ideally be reused
here, rather than each of us creating our own way of doing it.

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

Re: RFC: MCP-standalone Release Process

Matthias Wessendorf


On Fri, Oct 27, 2017 at 9:35 AM, Gerard Ryan <[hidden email]> wrote:
Leigh Griffin <[hidden email]> writes:

> Just want to throw it out there that the XML Licenser is going to be a
> requirement here. It's not a painful step in the above that you described
> but it's a step nonetheless. So if our code is anything outside of Java
> (maven based) or Node.js we might need to consider building a tool to
> create the licensing information or reach out wider to find a team already
> in flight on it.

Would that just be needed for the eventual Red Hat productization of it,
or is it also needed for the open source releases here?

OpenSource communities do that too, here a few examples of our own:

the second example is inspired by the release process of the ASF, requiring "LICENSE", "DEPENDENCIES" and "NOTICE" file as part of the (binary) artifact.
and a first step into what EAP does (for product)
 

In any case, I'd expect that other projects that Red Hat productizes
downstream, that are also Go projects, would also have this requirement,
right (e.g. OpenShift)?

yep, I was wondering that too, what they have
 
Whatever they're using, would ideally be reused
here, rather than each of us creating our own way of doing it.

+1000 

I started a little thread on the apb repo:

 

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



--
Project lead AeroGear.org

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

Re: RFC: MCP-standalone Release Process

Leigh Griffin
Sorry PTO for a week then backlog of mails.

It's formally needed for productisation but as Matthias pointed out it's good to be transparent in the community as well. 

Anything we as a company ship (product wise) needs to have a license so I would assume OpenShift have one. Could be worth reaching out to them to find out perhaps?

On Fri, Oct 27, 2017 at 9:40 AM, Matthias Wessendorf <[hidden email]> wrote:


On Fri, Oct 27, 2017 at 9:35 AM, Gerard Ryan <[hidden email]> wrote:
Leigh Griffin <[hidden email]> writes:

> Just want to throw it out there that the XML Licenser is going to be a
> requirement here. It's not a painful step in the above that you described
> but it's a step nonetheless. So if our code is anything outside of Java
> (maven based) or Node.js we might need to consider building a tool to
> create the licensing information or reach out wider to find a team already
> in flight on it.

Would that just be needed for the eventual Red Hat productization of it,
or is it also needed for the open source releases here?

OpenSource communities do that too, here a few examples of our own:

the second example is inspired by the release process of the ASF, requiring "LICENSE", "DEPENDENCIES" and "NOTICE" file as part of the (binary) artifact.
and a first step into what EAP does (for product)
 

In any case, I'd expect that other projects that Red Hat productizes
downstream, that are also Go projects, would also have this requirement,
right (e.g. OpenShift)?

yep, I was wondering that too, what they have
 
Whatever they're using, would ideally be reused
here, rather than each of us creating our own way of doing it.

+1000 

I started a little thread on the apb repo:

 

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



--
Project lead AeroGear.org



--

LEIGH GRIFFIN

ENGINEERING MANAGER, MOBILE

Red Hat Ireland

Communications House, Cork Road

Waterford City, Ireland X91NY33

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


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