Open Stack

On 2/29/16, 12:26 AM, "Andreas Jaeger" <aj at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev