[Rdo-list] python-*client packaging

[Steven Hardy]

On Thu, May 29, 2014 at 06:04:44PM -0400, Steve Gordon 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.
> 
> 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? 

The main reason not to do this IMO is that all of the upstream CI testing
is done against the latest released version from pypi, not the latest
client code from trunk.

My experience working on Heat (which uses pretty much all of the
python-*clients) is that regressions can and quite frequently do happen
when a new client version is tagged, which implies you're taking a
significant risk by taking a random bunch of git snapshots instead of a
release which has been verified by hundreds/thousands of CI runs upstream.

Here's one example which happened recently and is still not resolved:

https://bugs.launchpad.net/python-novaclient/+bug/1322183

Currently if you install latest novaclient from trunk, several heat unit
tests break, whereas the latest release works fine.

Part of the value of working with upstream devs to request a new release is
tagged, is they will hopefully have better visibility of potential blocker
issues, so the tag should only be applied when there are no known major
bugs and fixes/features are fully merged (as opposed to cutting a package
which contains a paritally implemented feature or bugfix, e.g a subset of a
series of patches have been merged and some are still under review).

I'd suggest the solution to this problem is just communication with the
upstream core devs and PTL's - IME most will be quite responsive if you
ask for a new client release for a valid reason.

Steve