On 2016-02-29 06:59, Steven Dake (stdake) wrote: > 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.
This is not needed, the CI system always rebases if you run tests. To get current tests, a simple "recheck" is enough. Also, we test in the gate before merging - again after rebasing to head. That should take care of not merging anything broken. Running recheck after a larger change will ensure that you have recent results. > 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. Andreas > Thanks in advance! > -steve > > [1] https://review.openstack.org/#/c/285625 > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
