[Rdo-list] Packaging the big tent (or at least part of it)
ggillies at redhat.com
Wed May 27 00:17:50 UTC 2015
On 05/27/2015 10:12 AM, Steven Dake (stdake) wrote:
> On 5/26/15, 2:41 PM, "Steve Baker" <sbaker at redhat.com> wrote:
>> On 27/05/15 09:23, Steve Gordon wrote:
>>> Hi all,
>>> At the community meetup, which we held in a somewhat lightning talk
>>> focused format due to time constraints, we touched on the subject of
>>> packaging the big tent  and said that if something was under
>>> OpenStack governance we (as a community, not we as in Red Hat) would be
>>> willing to accept it into RDO assuming somebody was willing to
>>> package/maintain it.
>>> Now packaging isn't really my end of things so I have to admit I
>>> haven't been paying exhaustive attention to the discussion about opening
>>> up the packaging infrastructure to external contributions, but I have
>>> been approached by one or two people who would be interested in
>>> packaging projects that have recently been added to the OpenStack
>>> namespace and they either develop or maintain a key interest in. Is
>>> there a quickstart I can point such potential contributors at?
>>>  https://etherpad.openstack.org/p/RDO_Vancouver
>> Heat had a design summit session which resulted in agreeing to remove
>> our contrib resources and bringing big-tent resources into the main heat
>> tree. The flow on from this is that Liberty Heat will depend on many new
>> python-*client projects that may not yet be packaged.
>> We do have criteria for these resources coming in-tree, such as being in
>> the openstack namespace, and being included in global-requirements.txt,
>> but we should have some consideration for the impact this has on
>> downstream packaging.
>> So either we just insist that downstream package all these clients, or
>> we come up with some further criteria for the in-tree resources for when
>> their client imports should be optional.
>> Any opinions from the RDO community would be most welcome.
> Packaging a client library is at most a 1 hour job. Testing it is another
> matter however :) The only downside I see is there has to be someone
> willing to do the packaging, meaning someone has to care about the project
> from an RDO perspective. I¹m happy to take on maintainership of the
> Magnum packages for RDO (not to include puppettizing them, because I am
> not learning puppet;), but for your proposal to work well, we need
> maintainers for all the things.
This is an interesting idea. As we start to get more projects under big
tent and into RDO (and the projects themselves might be in various
states in terms of maturity and stability), it might be worthwhile
having some documentation somewhere on the RDO website on what big tent
projects are in RDO, and which one or more people have taken the
ownership of packaging and maintaining them. This might be at a level
higher than RPMs itself. Essentially some form of process/governance to
officially identify what's in RDO (to avoid duplicates) and give people
a way of identifying who's responsible if patches/work is needed (and
who to contact to offer help assisting maintenance).
Does this make sense?
> If puppet isn¹t a requirement for inclusion in RDO, then it should be
> fairly easy to find volunteers in thee upstream communities to do the job.
>> Rdo-list mailing list
>> Rdo-list at redhat.com
>> To unsubscribe: rdo-list-unsubscribe at redhat.com
> Rdo-list mailing list
> Rdo-list at redhat.com
> To unsubscribe: rdo-list-unsubscribe at redhat.com
Principal Systems Administrator
Red Hat Australia
More information about the dev