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