Open Stack

The gate is still blocked apparently by yet another gate-breaking regression.  That regression is resolved in this change set:
https://review.openstack.org/#/c/285875/

Please rebase once that hits green and hits the repository.

From: Steven Dake <stdake at cisco.com<mailto:stdake at cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Sunday, February 28, 2016 at 10:59 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: [openstack-dev] [kolla] unblocking the gate

Hey folks,

It should be obvious that commiters should be testing their changes, but unfortunately this is not always the case.  With the recent state of the gate relating to the introduction of Docker 1.10.z breaking the gate  for 1 week followed by a keystone change upstream breaking the gate for one week, I'd like to make certain the gate stays green.

Jeffrey Zhang resolved the gate with [1].  I'd ask that everyone that has a patch in the queue rebase on master and resubmit their changes.  The result of that should be a green gate.  If you already have votes on your patches and they are rebased, I believe gerrit will leave the vote intact.  If not, the core reviewers who reviewed your patch originally will be happy to ack a simple rebase on master.

For core reviewers:
Please do not approve patches that do not pass the gate.  If the gate is broken, our priority should be on fixing the gate.  Please wait for workflows until the gate is green or a recheck has produced a green gate.  I realize our gate isn't perfect, but if its half-red it doesn't give developers a good sense of confidence their patch is correct (or not correct).  What ends up happening in that scenario is core reviewers end up having to pull down every change to personally test it.  We have a lot of work queued up, and the gate should provide some level of confidence that the change doesn't break things, especially with the recent addition of the dead-chicken testing nova boot operation.

When it comes to multinode, we will have to do manual testing, but I'd prefer to sort out any breakages during the RCs since manual testing won't necessarily test the same merge order as the core reviewers are using to manually test multinode.

Thanks in advance!
-steve

[1] https://review.openstack.org/#/c/285625
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160229/06722f09/attachment.html>