[PKG-Openstack-devel] Packaging OpenStack command line clients

[Thomas Goirand]

Hi,

On 03/13/2017 09:50 AM, David Rabel wrote:
> As I understand there are additional releases of the command line
> clients between the main OpenStack releases. We could package those
> versions as well, couldn't we?
> For example Ocata version of python-openstackclient is 3.8.1 , but
> current version is already 3.9.0 . So could we package both?

We should package 3.8.1 as part of the Ocata release, and we could as
well package 3.9.0 for Pike. However, IMO we should first work on Ocata.

> So, I think I do understand what's happening in debian/ now (except for
> some details maybe). Could I just go for it and try to package 3.8.1?

Unfortunately, we first need to get the Ocata build environment ready.
This mean having a Stretch image that we could use on upstream OpenStack
infra, so package can be built on it using Stretch (the plan is to
already stop supporting Jessie). Then we should get the 2 Debian
repository for stretch-ocata setup as well. Until then, unfortunately,
we can't do much packaging for Ocata or even Pike.

> Maybe one more question regarding the branches:
> Master contains upstream sources?
> stable/... also contain upstream sources?
> Afaiu stable/ocata p.e. is not only one version, but everything from
> 3.3.0 to 3.8.1 . Is that right?
> Are master and stable/... cloned from the upstream sources? How to bump
> them?

There is no need to do anything to have master and stable/* branches
updated, all is done automatically. This is maintained by the infra
itself, thanks to the option:

  options:
    - track-upstream

that has been setup in gerrit/projects.yaml in the project-config
repository (together with the URL of the upstream Git repo).

> debian/... seems to contain the packaging then. Here again: debian/ocata
> for example would not have to contain only one version, but everything
> from 3.3.0 to 3.8.1 ?

I'm not sure I understand your question, but let me try to answer
anyway. At a point in time, a debian/* branch would be the packaging for
a single version.

> So to start I would have to pull master and stable/ocata from the
> upstream repo?

No, you wouldn't. Let's say you want to package 3.8.1 for Ocata, you
would checkout the debian/ocata branch, then do this:

# git clone https://git.openstack.org/openstack/deb-python-openstackclient
# cd python-openstackclient
# git checkout debian/ocata
# git merge -X theirs 3.8.1

If the debian/ocata branch isn't created, we can make it (using the top
of the debian/newton branch) using the web interface. You would need
special ACLs to do that though.

Then you would fix the debian/control file to have the latest changes
from requirements.txt and test-requirements.txt (I usually do a diff to
see version changes), then edit the debian/changelog to get 3.8.1-1 as
the packaged version (write "* New upstream release" there), then do:

# git commit -a --amend

to get the packaging fixes together with the merge commit, then simply
push the CR to gerrit:

# git review

> Also please let me know what is the preferred workflow concerning the
> git repository.

What do you mean?

I hope this helps,
Cheers,

Thomas Goirand (zigo)