----- Original Message -----
From: "Jakub Ruzicka" <jruzicka(a)redhat.com>
To: rdo-list(a)redhat.com
On 26.5.2014 17:30, Pádraig Brady wrote:
> -------- Original Message --------
> From: Steve Gordon <sgordon(a)redhat.com>
> To: rdo-list(a)redhat.com
>
> Hi all,
>
> I was answering a question on ask.o.o [1] over the weekend that caused me
> to ponder the way we're packaging the python-*clients in RDO. As the
> clients don't really follow the formal integrated release cycle no release
> tag was created at the point of the Icehouse release for python-novaclient
> and instead the most recent tag is 2.17.0 created around 3 months ago.
I wrote basic overview on RDO wiki:
http://openstack.redhat.com/Clients
Rebases to latest version are required quite often.
> This is what we package and means we're missing functionality that was
> merged between this tag being created and the Icehouse GA, most notably
> *all* of the server group commands - the API for which was a fairly
> important (but late - via a feature freeze exception) addition to Icehouse
> for some users. I am wondering whether, given tag creation is basically on
> the whim of the individual maintainer upstream, we should be rebasing the
> clients from master more regularly instead of relying on the tags?
Important patches are backported on demand. I'm not strictly against
including upstream patches in packages and in fact, it was done like
that in the past.
I stopped including upstream patches because I found it quite confusing
- version says 0.6.0 but there are SOME bugs/features from 0.7.0... So
I'm rather working with assumption that *client devs know best when to
release a new version.
> The bug I filed for this specific issue with python-novaclient is
>
https://bugzilla.redhat.com/show_bug.cgi?id=1101014 but I imagine we
> experience similar issues with the other clients from time to time.
That's a perfectly valid reason for a selective backport but as you
mentioned in the bug, it would be best to release new version which
includes this and rebase to it in order to stay somehow consistent with
the rest of the world.
So, Russel, do you plan to release new novaclient anytime soon or shall
I backport?
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?
--
Steve Gordon, RHCE
Product Manager, Red Hat Enterprise Linux OpenStack Platform
Red Hat Canada (Toronto, Ontario)