[rdo-list] Python-shade in RDO

[Graeme Gillies]

Apologies for not replying sooner.

I'm still not 100% convinced that splitting up and fracturing RDO into
more repos is worthwhile, but I am happy to wait and see. If it's
possible for the RDO team to put together a clear piece of documentation
outlining what all the proposed and existing repos are, their names,
their purposes, and some examples and criteria of what type of Openstack
(and non-openstack, like openvswitch) packages land, that might make it
clearer for us to understand.

Regards,

Graeme

On 30/08/16 23:19, Haïkel wrote:
> 2016-08-30 8:23 GMT+02:00 Graeme Gillies <ggillies at redhat.com>:
>>
>> 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".
>>
> 
> Naming is easy to change, could be RDO clients and SDK, RDO Cloud
> users or whatever
> 
>> 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 Alan explained, we can't.
> 
> Actually, forcing release-independent projects like shade in
> release-specific repositories would make them more of a second-class
> citizen. Let's say that shade requires a newer version of clients than
> we can ship in Mitaka, that would force us to pin shade to an older
> release and maybe fork it to backport security updates.
> A separate repository would give us the flexibility to ship the latest
> and greatest of those projects without worrying to break stuff that
> will be installed in our cloud nodes.
> 
>> 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.
>>
> 
> That's poor workaround because we didn't have the flexibility to do otherwise.
> As for shade, stable releases requirements don't match
> release-dependent projects requirements and we do have a precedent:
> gnocchi.
> Gnocchi follows its own branching model and because of requirements,
> we have to collaborate with upstream devs to map specific gnocchi
> branches to an OpenStack release, though if you install gnocchi nodes
> in separated nodes, it does not matter.
> 
> 
>> 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.
>>
> 
> We can provide flexibility like we did with gnocchi but here I'd
> rather think of how could we provide better fits to our community by
> adding a new repository to fit the needs of cloud user
> 
>> 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
>>
> 
> *nods*
> 
> Regards,
> H.
> 
>>>
>>>> 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


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