7:11 a.m.
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