[PKG-Openstack-devel] Status?

[Ondrej Novy]

Hi,

2017-07-13 10:44 GMT+02:00 Thomas Goirand <zigo at debian.org>:

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

i'm trying, sorry if it looks weird to you. Just ask again and i will try
to answer again and ideally better :).

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

i tried to explain it, let's try it again. DPMT team is bigger than OS, so
it's higher chance someone from DPMT team will notice for example bugreport
in ML and try to fix it - team maintain package. This normally happens with
DPMT packages now.

But i have simple suggestion here. Why not try it? Maybe you are right and
nobody will help, maybe I'm right and somebody will help. But if we will
not try it, we will never know. And it's always possible to move packages
back.

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.

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

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

ok, let's skip this. I didn't wanted to start flame here. I'm fine with
current 'git archive' flow without pristine-tar.

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

where I sad i don't want to package intermediate Openstack releases? I want
to package them and if newer OS release is released before Debian release,
package them and upload them to unstable.


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

i don't want to maintain old Openstack releases which are EOLed at all
(with Debian stable exception, but that's must have). So what "risk" are
you talking about?

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

no, why? I WANT to have newest OS release in stable and in
old-stable-backports.


> >   * newest version of OS in unstable+testing
>
> If you do that, then you need to use branch names after the release
> names of OpenStack.
>

no, i don't see your point here. I want to have branch "debian/unstable"
with newest OS release, uploaded to unstable and later after migration to
old-stable-backports.

I think we don't understand each other.

I suggest this branches (same as http://dep.debian.net/deps/dep14/):

debian/jessie
debian/stretch
debian/stretch-backports (if is needed to do any changes in backport)
debian/unstable

Everytime new OS is released, commit it to debian/unstable and upload it to
unstable. After unstable->testing migration, upload it to stretch-backport.
If there is any bug in stable/Stretch, fix it in debian/strech, upload it
to proposed-updates. Dtto for Jessie. In RC phase of OS release, use
debian/experimental.

Simple and clean layout which matches Debian suites.

-- 
Best regards
 Ondřej Nový

Email: novy at ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/openstack-devel/attachments/20170713/6d781d64/attachment-0001.html>