[Rdo-list] python-*client packaging

[Jakub Ruzicka]

On 30.5.2014 11:06, Steven Hardy wrote:
> 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.

+1

> 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.

Not only CI but also folks who actually use them. Other distros package
tagged versions as well. IMHO using tagged versions is much safer than
random commit with random new bugs.

It's not unusual for clients to release bugfix release very shortly
after new release due to bugs discovered as people start using it. If we
chase master, I'd expect *much* more breakages.


> 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.

Well said, I fully agree with this. If there is something missing in the
latest tagged build, then poke dev/PTL to release new version. If that's
not possible for some reason, I can easily do a backport - it's a matter
of opening a bug.


Cheers
Jakub