[Rdo-list] python-*client packaging

[Steve Gordon]

----- Original Message -----
> From: "Jakub Ruzicka" <jruzicka at redhat.com>
> To: rdo-list at redhat.com
> 
> On 26.5.2014 17:30, Pádraig Brady wrote:
> > -------- Original Message --------
> > From: Steve Gordon <sgordon at redhat.com>
> > To: rdo-list at 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)