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

Mon Apr 13 09:54:50 UTC 2015

Hi Thomas,

On Mon, Apr 13, 2015 at 10:09:39AM +0200, Thomas Goirand wrote:
> >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.

Ahhh, fine.  Perhaps I should have read this page more thoroughly.  I
did not intended a competing method.  Malihe, in case you decide to
recreate the manila repository I'd advise to check out this method which
is established in the openstack team.

> >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.

OK.

> 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).

So pkgos-alioth-new-git seems to configure KGB, right?

> 3/ I'd prefer that we just have Gerrit, and register this type of
> list to all Gerrit repositories when that it setup.

Fine for me - but what exactly does Malihe need to do to use Gerrit?
I have not found the string "gerrit" on the openstack alioth page.

> > 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.

At office time I'm excluded from IRC (and yes, I know how to deal with
this - but I will not this).  I think it will work if Malihe will send
me some pull request.

> >>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.

Can you please give some hint where Malihe can read about tag based
packaging?  I'm used to the workflow I posted in my other mail but I
think it is most helpful if Malihe adapts to what is used in openstack
team.

> > 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.

I have spotted several issues in the Ubuntu packaging which need to be
changed even after a quick view.  I think it is ensured that we will not
simply the Ubuntu package - and we for sure will ask for your final OK.

BTW, what do you think about my last suggestion to turn the d/watch
files to github and take the latest version from there (which is either
later than the vivid version if you include (\.0b\d) in the regexp
or older if you decide for stable releases)?

> > 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.

OK, Malihe, please follow this advise.  I admit I also need to adapt to
this workflow but I'll try.

> > 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.

Thanks for the explanation.

> > 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...).

Malihe, it seems we are now both learning. :-)  Please follow this
advise and post any problem you might have.  I'll try to help and Thomas
will fix me if I'm wrong. :-)

Hope this is fine for all involved parties

    Andreas.

-- 
http://fam-tille.de