[rdo-list] Python-shade in RDO

[Graeme Gillies]

Apologies for top posting, trying to resurrect this thread.

So if I am understanding correctly, the outcome from this email thread
was that a new repo in RDO was going to be setup for packages in
Openstack big tent which do not follow the "stable branch" model.

Was this ever done? If so, are we in a position to put python-shade
inside it? I recently rebuilt it for centos 7 in COPR

https://copr.fedorainfracloud.org/coprs/ggillies/rdo-newton-extras/packages/

And it works fine.

If we haven't gotten to the point of creating this repo, what do we need
to do to get this done? How do we move forward from here?

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