[PKG-Openstack-devel] Status?

[Thomas Goirand]

Hi,

While it's nice to explain your plans, it looks weird to me to just
dismiss all of my points of argumentation when I express concerns.

My answer below.

On 07/10/2017 04:27 PM, Ondrej Novy wrote:
> Hi,
> 
> 2017-07-10 15:25 GMT+02:00 Thomas Goirand <zigo at debian.org
> <mailto:zigo at debian.org>>:
> 
>     IAs I wrote previously, moving packages to other team wont help if
>     nobody
>     is volunteering for the maintenance. Also, anyone can join the OpenStack
>     PKG team. The only thing will be that you'll be forced into using
>     git-dpm, which everyone recognize as super bad. So what are you trying
>     to achieve here?
> 
> 
> me != everyone. :) I don't have problem with git-dpm. And it looks like
> DPMT is moving towards gbp pq too.
>  
> For me it was (is) much simpler to maintain packages inside DPMT. Git
> flow is straight forward, there are people which are sponsoring uploads
> (p1otr, matt, ...), community is big enough to help. And using pybuild
> is simple.
> 
> And i think all wide-useable python libs should be in DPMT, because it
> makes sense to have this things in one place.
> 
> Some people can have problems with maintaining packages in OS, because
> they don't understand OpenStack and OS-pkg tools. But they know Python,
> and know pybuild. Community around DPMT+pybuild si much bigger than
> around openstack-pkg-tools.

Still, the main issue is finding contributors. How do you address it?
Simply moving packages from one team will *not* solve it.

>     >   * create brand new repositories in alioth from current version in
>     >     Debian Archive with "gbp pq" + pristine-tar layout, compare with
>     >     current repository states in Gerrit
> 
>     The issue with pristine tar, is that, from upstream, they contain the
>     AUTHOR file, which is of no interest (we care who is the copyright
>     holder, not the authorship), and the huge changelog based on git
>     history. I've been already flamed by the FTP masters because small
>     packages like nova-compute-* became insanely huge (ie: megs instead of
>     kbytes). So, you'll have to upload modified +dfsg tarballs, which
>     completely defeat the purpose of using pristine-tar. That with the other
>     issue that pristine-tar is by design broken (because tar doesn't produce
>     the same output from version to version, and same for XZ).
> 
> 
> +dfsg repack with pristine-tar is simple and working fine (even with
> uscan). Dfsg repacking with current layout is much harder and in Gerrit
> it's not possible at all (currently).
> pristine-tar can produce same output (it's purpose of pristine-tar),
> it's used by Ubuntu and they say: No problems at all. It's used by DPMT:
> No problems at all.

You can't say "no problem at all" when the original author of
pristine-tar decided to stop maintaining it because it's broken by design.

> And i don't see point why we can't have gzipped version of CHANGELOG and
> AUTHORs file in /usr/share/doc/.

That's exactly the kind of answer what made me write the first sentence
of this reply: you are dismissing my point of argumentation without
replying to it, so we're not moving forward in a healthy exchange of
ideas, but turning in loop instead. Hopefully, this is happening only
because you haven't paid attention to me reply, so I'll just write it
once more.

As I wrote: the problem is *size* (yes, even with gzip). Besides this,
the AUTHORS file is useless in the context of Debian, who cares about
copyright holding, not authorship. Packages have been rejected by the
FTP masters on this ground, so this is *not* coming from me,
unfortunately. Like it or not, you *must* address this issue.

> I'm explicitly adding them to my
> packages. Can you point me to "megabytes" sized changelog in upstream
> git please?

In upstream git, no: they are generated using git by the release tools,
when doing a "make dist". Try with nova, for example: version 14.0.7 has
a Changelog of 1.4 MB.

>     So, why not keeping the workflow we had before switching to infra?
> 
> because 'git archive' can't reproduce bit by bit same tarball.

And so can't pristine-tar, which made Joey Hess stop maintaining it. The
issue is the same, it's simply hidden by patches in GNU tar. Also,
source packages from upstream are using gzip instead of xz.

> I want to
> use "uscan" with GPG signature check. That's much safer way.

Why safer? Is this just for the gpg signature? This makes no sense,
since there is also signed gpg tags. Also, we're talking about repacking
tarballs because of files we need to get rid of (ie: Changelog and AUTORS).

> You are saying pristine-tar is broken, but current flow is broken much
> more. We can't reproducible create original tarball.

The point is: we *do not* want original tarballs which may have
artifacts we don't want, and missing files (for example, "tests" folder
in many cases). Using the original git repository is safer in this regard.

>     >   * use one branch per Debian release, don't try to have "more
>     supported
>     >     version of OS in Debian stable"
> 
>     That you do not wish to support each and every release of OpenStack in
>     Debian is one thing, but then you must at least provide an installable
>     version so that users have an upgrade path. And then, one branch per
>     OpenStack release is mandatory.
> 
> 
> from Debian POV: It should be possible to upgrade from old-stable to
> stable. Version diff between old-stable and stable will always be > 1.
> So we need to found other solution for upgrades. Solution is not to
> create unofficial OS repository with intermediate versions just for
> upgrades.

Right. Though hopefully, bikesheds will be there at some point.

Also, the most important point is probably using branch names after the
OpenStack releases. There's simply no way you'll be able to maintain
OpenStack properly if you just use Debian release names instead. I've
been there and done that, and quickly understood it doesn't work. Also,
are you willing to just stop packaging releases not aimed at the next
Debian stable? IMO, doing this isn't realistic, as you need to address
issues as they come. For example, Horizon (and many of its dependencies)
being broken with Django 1.11 right now.

There's no way you can just "skip release" without a huge amount of work
for the db migration. I don't think it's nice for users either. First
some will see Debian as a 2nd class citizen for OpenStack, and 2nd you
have the risk that Debian stable branch gets security bugs for which you
wont have patches, because the OpenStack branch has been EOLed for too long.

Last, it means you're dropping the idea of using official Debian
backports for the latest release.

So, IMO, you really should rethink your plan here.

>     Though I would strongly suggest that if you want to maintain OpenStack
>     seriously in Debian, you do package each and every version of OpenStack,
>     and if possible very beta release as well. Otherwise, what will happen
>     is what is happening right now: loads of RC bugs get filled, because the
>     Python suite evolves (Django 1.10, Python 3.6, etc) and you got to stay
>     current.
> 
> 
> I agree we should support every new version in Debian. Periodically
> upgrade version in unstable and fix bugs of older releases in stable.
> 
> What I suggest to have is:
> 
>   * newest version of OS in unstable+testing

If you do that, then you need to use branch names after the release
names of OpenStack.

>   * fix bugs in released distro version of OS in stable / old-stable
>   * create backports of newest version of OS from testing to
>     stable-backports
> 
> All of this in official Debian repositories.
> 
> And don't have this:
> 
>   * support older versions of OS in unstable+testing
>   * support older versions (other than released with that distro) of OS
>     in stable

Nobody suggested one of the above points.

Cheers,

Thomas Goirand (zigo)