[PKG-Openstack-devel] Migration of packaging development workflow to OpenStack project

[Thomas Goirand]

On 09/06/2016 03:16 PM, Corey Bryant wrote:
> For my work personally, this is a step backwards.  If I have to get a +2
> on every package change I make, it's going to slow down my workflow
> significantly.

You don't. If you are core, you can self-approve your own patches. I
know that's not what everyone does in OpenStack, but for trivial
patches, I do believe it's ok.

Also, you have to remember that when I upload any of your changes to
Debian, I do a careful review of it, because I will be held responsible
for any problem. So from my perspective, it wont change anything to
review. It's even better, because we have a log in the #openstack-pkg
channel.

> For example there are many times during the cycle where
> we sprint on openstack dependencies, and it's normal to get 10-20
> packages pushed/uploaded in a day and then move on to the next task. If
> I have to wait on +2's for all those deps now, then I'm moving backward
> and this is slowing down my workflow.

I believe it's a question of self discipline to tell which patch needs a
review or not. Many will not. Some will do.

Another thing is that we'll be able to have proposal bots. Imagine the
following scenario:

1/ Upstream release a new version of oslo.config
2/ The proposal bot catches that, and proposes a change in the
packaging, including:
- fix of changelog
- change of (build) dependencies
3/ When one of us sees the proposal bot change, he just approves it, and
the package builds

> My workflow goes from:
> 
> 1) clone repo
> 2) make change
> 3) push repo
> 4) upload
> 
> To:
> 
> 1) clone repo
> 2) make change
> 3) initiate review
> 4) ping core dev for +2
> 5) wait for merge
> 6) possibly repeat steps 4+5
> 7) upload

It is my hope that at some point, the workflow for *many* packages will
be something lit this:

1) Login to Gerrit
2) Approve the changes from the proposal bot (which can even have a full
Tempest CI test to make sure we're not breaking anything)
3) Clone the result, and upload to distros

We do have requirements parsing scripts under development, though it
didn't take the direction I wanted. However, it could be rebooted.

>From what I experienced, the Infra system didn't change much of my
workflow. The only annoyances are things in infra which we can later fix.

Let me give a few example of things we should improve:
* the CI currently fails to fetch some dependencies. That's due to the
fact we're using httpredir.debian.org, instead of a real Debian mirror.
All of that is due to the fact that the infra mirror is currently done
using reprepro, and it's not signed, therefore, it can't be used by
sbuild-createrepo. This will be fixed at some point.

* The CI needs to build packages 3 times until they get in the reprepro
deb archive, which is annoying (we sometimes need to wait for a
dependency to be available to go to the next, and that's especially
frustrating right now, at the bootstrap phase). That will be fixed when
we have Zuul 3, I've been told.

Cheers,

Thomas Goirand (zigo)