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

[Ondrej Novy]

Hi,

2017-02-22 11:54 GMT+01:00 Thomas Goirand <zigo at debian.org>:

> I hope you don't mind even if you sent me a mail to me only: I'm
> forwarding this to the list, so we can discuss it as a team. Hopefully,
> we'll have improvements.
>

np.

>  3. it's always not possible to have one commit per change (i need to
> >     git commit --amend after merge)
>
> Could you expand on this? I don't understand why there's a problem, and
> why one would need to do a --amend after merge.
>

ehm,
https://wiki.openstack.org/wiki/DEB-packaging#Releasing_a_new_upstream_release_package

You MUST use --amend after git merge.

Cite: Note that the fix of debian/changelog and debian/control should be
done in the same single commit as the merge commit, otherwise the package
will fail to build.

So in 1 commit I need:

   - merge upstream
   - change d/changelog
   - change d/control for deps
   - add d/patches which fixies build

This is crazy. I want to do as small commits as possible, at least one
commit = one changelog entry.


> >  4. it's hard to manage deb-auto-backports. It took me a day to fix
> >     auto-backports just to upload new Swift version
>
> True. Though it has the huge advantage that it keeps backports
> up-to-date, which was never the case with the hack system of doing it by
> hand. Also, you never had to take care of it, because *I* was doing it
> by hand, sometimes cheating and just ignoring build problems (shame on
> me). It was even more painful by hand...
>

but that's theory. I waited ~ week for fix and then i fixed it myself. We
can't depend on single man to do critical job. We need solution which
anyone can fix :). Current solution is hackish. Example: If you need to add
new package for auto backports, every other package is checked for update
and if there is update, it gets updated. We should change this and update
packages only if it's needed / desired. Next: We should prefer depedency
packages from official jessie backports if they are newer and (auto-)remove
old one from our repo.

>  5. it doesn't build packages for unstable - which is important, because
> >     we are uploading to unstable and instead it builds/checks Jessie
> >     backports (which is less important)
>
> We could add that feature. Also, it is my view that one should attempt
> an sbuild build on Sid before sending a CR. With the old system, we also
> had the issue.
>

yep i can say anyone should do sbuild on Jessie backports before doing CR
too. So why we have gating for Jessie bpo? Because gates are here for
checking if people are doing correct thing. And because we are uploading to
Sid, we must be sure it builds on sid (with deps package only from sid).

>  6. only cores can update package to new upstream version (merge commit)
>
> So far, it hasn't been an issue. We can also have a very liberal policy
> as to who's core if we do have a problem. Also, there's many ways to
> configure ACLs, we could get them to allow everyone to do merge commits.
>

it hasn't been issue because everytime my colleague needed to do CR I added
them to team and then removed them :). So let's change ACL i think.

>  7. we still don't have one simple thing - ocata branches. Something I
> >     can do myself in Alioth for less than 1 minute
>
> As I wrote before, the Ocata branches aren't the problem. The reprepro
> new Debian repo for Ocata is.
>

so:

8. add repo for Ocata

Thanks.

-- 
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/458155ce/attachment.html>