On 2/29/16, 12:26 AM, "Andreas Jaeger" <a...@suse.com> wrote:
>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. Andreas, Thanks for the recheck information. I thought the gate ran against what it was submitted with as head. We don't have any gate jobs at present (or many) they are mostly check jobs, so its pre-merge checking that we need folks to do. Regards, -stev > >> 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 __________________________________________________________________________ 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