[PKG-Openstack-devel] [MoM] Packaging manila

[Thomas Goirand]

On 04/11/2015 11:43 AM, Andreas Tille wrote:
> Hi Malihe,
>
> On Sat, Apr 11, 2015 at 12:04:12AM +0430, Malihe Asemani wrote:
>>> Please see the attached log from IRC.  Zigo will add our IDs to enable
>>> us commiting to debian-openstack Git.
>>
>> The users is added. thank you and thanks Zigo :)
>
> Same for me.  Thanks Zigo.
>
>>>>>>     ssh://git.debian.org/git/openstack/manila.git
>>>>>>
>>>>>> commit the current Ubuntu code base and proceed from here.
>>
>> How can I add the source code there? I think some one should create manila
>> git-repo on the server, as first step.
>
> This "someone" can be any member of the team - in other words you can do
> it yourself.  In the teams where I'm involved exists a setup-repository
> script.  I took the freedom to cut-n-paste from Debian Med and created
>
>      /git/openstack/setup-repository

As per http://openstack.alioth.debian.org/, I use this:

"pkgos-alioth-new-git openstack"

from within a new git tree. This should be slightly adapted if you're 
not add (to handle a different username with "-guest" at the end). I'd 
accept such a contribution to fix the scrip which is in openstack-pkg-tools.

> Zigo, what do you think about an openstack-commit mailing list.

I'm not against it per-say, but:
1/ We already have #debian-openstack-commits on IRC which tells about 
new commits.
2/ It *must* be configured to *not* publish upstream commits when we do 
a merge (because there's going to be hundreds of mails considering the 
number of commits).
3/ I'd prefer that we just have Gerrit, and register this type of list 
to all Gerrit repositories when that it setup.

 > We
> could simply copy the hooks from Debian Med.  It also installs KGB which
> forwards the commits to the IRC channel.

We already have a KGB bot, as per above. Please join the channel.

>> Or maybe I should request a personal
>> repo as first step and push the code there ?
>
> No, I think a usual repository is the best way to go.

Agreed.

> If you want to
> become a fully qualified team member of the OpenStack team I see no
> reason to start in a sandbox. :-)

Exactly!

On 04/12/2015 11:29 PM, Malihe Asemani wrote:
 > I created the repository using the script, and pushed the source code
 > of current-stable release of Manila on Master branch.

There's absolutely no need to publish the master branch on Alioth. Only 
the packaging branch (ie: debian/kilo) is needed, if you use tag-based 
packaging.

 > There is a
 > newer version of Manila on Ubuntu repository too. which one is the
 > best? current stable one
 > 
<https://launchpad.net/ubuntu/+source/manila/2014.1~git20140220-0ubuntu13> 
on
 > Utopic, or pre-release one
 > <https://launchpad.net/ubuntu/+source/manila/2015.1~b3-0ubuntu1> on
 > Vivid? I should mention that I left the commented (hook-related)
 > lines in /git/openstack/setup-repository script unchanged.

You should use the vivid version. But please make sure that you don't 
just take what's in Ubuntu and build it for Debian, as lots of standards 
aren't the same. Have a look at how configuration files are handled with 
Debconf for example.

 > BTW, I read that there are different branches on Debian git repo for
 > upstream, and Debian releases. Despite all of these, I have uploaded
 > the Ubuntu source-code of Manila on our Master branch. Is that OK?

It's not ok, unfortunately. There should never be any branch called 
"master" on our Git repository, but a branch named after the OpenStack 
release. In our case, it'd be debian/kilo (as this is the OpenStack 
release we're working on right now).

So, the way to do it is:

git clone git://github.com/openstack/manila.git
cd manila
git tag 2015.1_b3 2015.1.0b3
git reset --hard 2015.1_b3
git checkout -b debian/kilo
git branch -d master
# <add here your debian folder for the packaging>
git add debian
git commit -a -m "Initial debian folder"

Make sure that, when you add your Debian folder, you get something like 
this in debian/gbp.conf:

[DEFAULT]
debian-branch = debian/kilo
upstream-tag = %(version)s
compression = xz

[git-buildpackage]
export-dir = ../build-area/

Then doing "pkgos-bop" should rebuild the package correctly.

On 04/13/2015 09:09 AM, Andreas Tille wrote:
 > When using git-buildpackage you usually have three branches:
 >
 >     upstream:     plain upstream source as imported from upstream tar
 >     debian:       upstream branch + debian packaging
 >     pristine-tar: some auto-generated metainformation to enable md5
 >                   equivalent tarball (usually you do not manually deal
 >                   with this)
 >
 > How do you get the said layout.  Here I would like to refer to the
 > Debian Med policy[2].  It recommends
 >
 >     git import-orig --pristine-tar /path/to/package_version.orig.tar.gz
 >
 > which would import the orig.tar.gz (which does *not* contain any
 > debian/ dir in normal cases) into the repository and automatically
 > creates the needed branches.  Than you manually create the debian/
 > dir add the files that you need and commit these in the master branch.

We're not using pristine-tar, because of efficiency: maintaining 
tarballs is a very slow process, as they may be very big, and their 
number increases with each (beta and RC) release, which isn't nice. 
Also, there's now way to tell in which kind of version of tar the 
tarball will be generated, and therefore, we may hit the issues which 
Joey Hess explained about the non-reliability of pristine-tar (which 
made him orphan the package). Therefore, I've been using git tag based 
packaging, as per what I just explained above.

 > BTW, I have some additional data point about the choice of the
 > version to package.  I would package the latest version that is
 > reported by
 >
 >     uscan --verbose --report

The debian/watch file which I do are using the github tags. For example:

version=3
opts="uversionmangle=s/\.(b|rc)/~$1/" \
https://github.com/openstack/nova/tags .*/(\d[\d\.]+)\.tar\.gz

What we should do, is just "git merge -X theirs <LAST-TAG>" in the 
packaging branch (once the initial repository is created, of course...).

Cheers,

Thomas Goirand (zigo)