[Rdo-list] python-*client packaging

Russell Bryant rbryant at redhat.com
Mon Jun 2 15:55:33 UTC 2014


On 05/29/2014 06:08 PM, Dan Smith wrote:
>> I guess what I am driving at is that the process of creating a tag in
>> the OpenStack client projects occurs at pretty arbitrary points in
>> time based on the needs of other OpenStack projects that want to set
>> requirements on them rather than anything relating to the needs of
>> downstream distributions such as RDO or RHELOSP. Because no other
>> OpenStack project needed the particular functionality (and fixes)
>> added to python-novaclient in the last three months no new tag was
>> requested nor created. In this case it means we're missing some 84
>> odd commits made since the 2.17.0 tag was created.
> 
> Yup, exactly. We've had features that were cross-project that had client
> changes required. We'd push the change into nova, then push into
> novaclient, tag the novaclient, update requirements for the other
> project, push that change, etc.
> 
> On the other hand, we also have "huh, we haven't done a client release
> in a while" moments. For examples like nova events, instance groups,
> etc, I think it makes plenty of sense to stay current on the client
> packages.
> 
>> Given this what I'm wondering is if there is any reason we shouldn't
>> move to a model where we rebase the python-*client packages to the
>> latest git commit at each milestone (J-1, J-2, J-3, RC, GA),
>> regardless of the existence of a tag, to ensure we are always picking
>> up the latest changes?
> 
> Assuming proper testing of course, +1 from me.

Agreed.  It really should be safe to use from any commit.  That's
certainly the intention.  As Dan mentioned, we're completely
non-disciplined about when a client actually gets tagged.  Practically
that's just about getting something uploaded to pypi occasionally, and
that's not terribly relevant for us anyway.

-- 
Russell Bryant




More information about the dev mailing list