[PKG-Openstack-devel] Improving the infra CI/CD for Deb packaging

[Ondrej Novy]

Hi,

2017-02-22 18:37 GMT+01:00 Thomas Goirand <zigo at debian.org>:
>
> In which way does this differ from what we had on Alioth + Jenkins build
> server? (This is retorical, let me answer) Well, before, we could push a
> merge, but then there was a chance the package couldn't build. Now, we
> make sure than 100% of the time, the package *can* build. So IMO it's a
> very good thing that now, the merge commit must contain fixes so the
> package continues to build. On top of this, we have a consistent git
> history, were we always can build.
>

this is not retorical, because there is difference. On alioth I can do many
commits and push "when it's ready" and when it can be build. This makes git
history much cleaner. It needs to be buildable after push, not after
commit. Now I need to make all changes in one commit. Git history is
completely useless/unreadable now.

BTW: Same flow are used in github+travis. Merge request (which can be more
than one commit) needs to be buildable, not all single commits.

> but that's theory. I waited ~ week for fix and then i fixed it myself.
>
> I don't remember what that was. Can you refresh my memory?
>

https://github.com/openstack/deb-auto-backports/commits/debian/newton
14-18 November. Enable, disable, enable some of them, ...

If I remember correctly I wanted newer pycodestyle and libgit2.

There's 2 options for us to use: --download-from-jessie-backports (which
> I used for a few packages which we couldn't build), and -d
> jessie-backports. If you and everyone else believe it's the best option
> for us, then I don't have any objection to use extensively the -d
> jessie-backports (which I prefer over --download-from-jessie-backports
> so we check if the package can be built). The reason why I think it's a
> good idea, is because this way, we take advantage of the maintenance
> work done within Debian directly, which is a very good thing.
>

I mean something different. I would use jessie-backports official backports
(in /etc/apt/sources.list) during our build and only if package is not in
official j-bpo repo, add them to auto-backports. And only for short time,
because we should upload them to j-bpo.

So simple flow:
* build our packages using official j + j-bpo repos
* when i need newer/completly new b-d which is not in j-bpo, add it to
auto-backports
* upload it to j-bpo
* remove from auto-backports

So keep auto-backports as small as possible. Example: Why we should build
debhelper for j-bpo ourself if there is working+tested version in j-bpo
already? We are uploading final packages to j-bpo repo, so it MUST work
with other j-bpo packages. And if we don't want wait for dak/other
maintainers, use auto-backports.

-- 
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/20170222/1784c903/attachment.html>