[rdo-list] Python-shade in RDO

[Graeme Gillies]

On 29/08/16 19:17, Haïkel wrote:
> 2016-08-29 1:19 GMT+02:00 Graeme Gillies <ggillies at redhat.com>:
>> On 26/08/16 16:31, Alan Pevec wrote:
>>>
>>> On Aug 26, 2016 07:09, "Graeme Gillies" <ggillies at redhat.com
>>> <mailto:ggillies at redhat.com>> wrote:
>>>
>>>> Sorry I'm a bit confused here, are you actually saying that shade can't
>>>> be in RDO because it lives in a slightly different git repo location, a
>>>> location by which, is still referenced as perfectly valid for openstack
>>>> projects in Big tent
>>>>
>>>>
>>> https://github.com/openstack/governance/blob/master/reference/projects.yaml
>>>>
>>>> I'm also confused why you think the clients should also be moved out of
>>>> rdo into another repo as well. This is just splitting the repos up
>>>> needlessly isn't it? Shade, like oslo and other Openstack libraries,
>>>> should be part of RDO.
>>>
>>> Problem with Shade is that it'd branchless so putting it into one RDO
>>> release repo won't work. That's why separate repo is suggested, which
>>> would also solve the other issue Haikel mentioned: upstream infra
>>> enables RDO repo only to get openvswitch which is not in EL7 base, so we
>>> would put that in rdo-extras.
>>>
>>> Cheers,
>>> Alan
>>>
>>
>> Sorry just so I am 100% clear here, in order for python-shade to just go
>> into RDO it would need to have stable release branches, which I would
>> assume match the standard Openstack release naming (liberty, mitaka, etc).
>>
>> Pulling back a bit, can we talk about the charter regarding RDO and
>> packaging Openstack projects (which fall under big tent)?
>>
>> Under big tent, projects are not beholden to the explicit 6 month
>> release cycle that has been mandated in the past. Most projects choose
>> to stick with it, but there are a couple which don't.
>>
>> The official governance documentation [1] references projects can have
>> the following release management
>>
>> release:cycle-with-milestones
>> release:cycle-with-intermediary
>> release:cycle-trailing
>> release:independent
>>
>> The ones that are probably most interesting to this discussion are
>> release:cycle-trailing and release:independent (of which shade uses).
>>
>> Can we get the packaging documentation modified to include an official
>> policy on how the projects with the different release cycles are to be
>> treated? I don't believe that projects with release:independent should
>> be excluded from RDO, in fact, they definitely aren't because we package
>> and ship rally as part of RDO and that uses release:independent.
>>
> 
> (CC'ing Paul, as I would like to hear openstack-infra feedback on that point)
> 
> Yes, we will discuss that item during our next meeting.
> If there's agreement to create a rdo-extras repository, projects
> tagged release:independent are candidate to be shipped in that
> repository.
> 
> What we need to figure out is what *exactly* it should contains,
> provisionnally, it is:
> * shade + latest clients from stable branches
> * projects tagged release:independent
> * minor utilities only available through EPEL and useful for
> openstack-infra (should it be a separate repo?)
> 
> Regards,
> H.

I would really implore you to think very carefully about splitting out
release:independant projects into a separate repo, especially one with
the name "extras".

Fracturing the repo setup only reduces usability, causes confusion, and
for those projects that choose an independent release model, it makes
them feel like second class citizens and less likely to want to care or
be part of the RDO community.

As I've already mentioned, we already ship a release:independant project
in the normal repo, and I fail to see from a technical level why others
can't do the same. Simply ship their latest stable release in the
current stable repo.

A lot of the projects that choose release:independant are smaller,
perhaps a bit newer, and still in a growth phase. If RDO is able to show
that those projects can be a part of RDO like everything else, it means
they are more likely to participate in the community, as it makes their
software more accessible.

Remember the goal here is to grow the community and have as many
projects participating in RDO as possible. Encouraging the smaller
projects to do so is a great way to help that.

Regards,

Graeme

> 
>> Regards,
>>
>> Graeme
>>
>> [1] https://governance.openstack.org/reference/tags/
>>
>> --
>> Graeme Gillies
>> Principal Systems Administrator
>> Openstack Infrastructure
>> Red Hat Australia


-- 
Graeme Gillies
Principal Systems Administrator
Openstack Infrastructure
Red Hat Australia