Re: [openstack-dev] [GBP][Heat] Group-based Policy plug-in for Heat

2015-06-18 Thread Robert Kukura
Zane, I will fix this (and the other GBP packages) as soon as I possibly 
can. I agree it would be better to move the GBP heat support into the 
heat repo, either main tree or /contrib, but others on the GBP team 
would most likely handle that. Seem reasonable for liberty.


Thanks,

-Bob

On 6/17/15 8:56 AM, Zane Bitter wrote:
Every day I get an email about broken dependencies for the group-based 
policy Heat plugin in Fedora (openstack-heat-gbp), because the version 
of Heat it depends on is capped. Two points:


1) Would whoever maintains that package (Bob?) please fix it :)

2) Why was this plugin not submitted to /contrib in the Heat repo so 
that it could be continuously tested  maintained against the Heat 
code base, thus avoiding any compatibility problems with future 
versions? This is the entire reason we have /contrib. In fact, if you 
think the resources are in close to their final form (i.e. the API is 
not super experimental still), I think we may even be willing to 
accept them into the main tree at this point.


cheers,
Zane.

__ 


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [GBP][Heat] Group-based Policy plug-in for Heat

2015-06-17 Thread Zane Bitter
Every day I get an email about broken dependencies for the group-based 
policy Heat plugin in Fedora (openstack-heat-gbp), because the version 
of Heat it depends on is capped. Two points:


1) Would whoever maintains that package (Bob?) please fix it :)

2) Why was this plugin not submitted to /contrib in the Heat repo so 
that it could be continuously tested  maintained against the Heat code 
base, thus avoiding any compatibility problems with future versions? 
This is the entire reason we have /contrib. In fact, if you think the 
resources are in close to their final form (i.e. the API is not super 
experimental still), I think we may even be willing to accept them into 
the main tree at this point.


cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev