<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 11, 2014 at 2:44 AM, Andreas Jaeger <span dir="ltr"><<a href="mailto:aj@suse.com" target="_blank">aj@suse.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 08/11/2014 09:36 AM, Tom Fifield wrote:<br>
> On 11/08/14 13:20, Andreas Jaeger wrote:<br>
>> On 08/11/2014 05:26 AM, Tom Fifield wrote:<br>
>>> On 10/08/14 22:21, Andreas Jaeger wrote:<br>
>>>> With the addition of a non-voting check for linked URLs, we need to<br>
>>>> touch Jenkins jobs and our tox.ini everywhere. I suggest to do this<br>
>>>> differently: Combine the tiny voting jobs in one job and do the same<br>
>>>> for<br>
>>>> non-voting jobs.<br>
>>>><br>
>>>> So, instead of:<br>
>>>> * check-syntax<br>
>>>> * check-niceness<br>
>>>> * check-deletions<br>
>>>> * check-links<br>
>>>><br>
>>>> we would have:<br>
>>>> * check-voting<br>
>>>> * check-non-voting<br>
>>><br>
>>> May I ask what would be posted on the review comment? Would we still<br>
>>> have a posting of all of the various job results {syntax, niceness,<br>
>>> deletions, links} and FAIL/PASS next to them? Or would it be just<br>
>>> {voting, non-voting} PASS/FAIL.<br>
>><br>
>> It would be<br>
>> voting: PASS<br>
>> non-voting: PASS<br>
>> check-build: PASS<br>
>> check-lang: PASS<br>
>><br>
>> And then you need to click on the link for details - like you do today -<br>
>> but also to read out which check failed,<br>
><br>
> Ok, if that's the case, my preference would be to leave it as it is -<br>
> with each check giving its own explicit pass/fail.<br>
><br>
> Aside from my personal preference, I believe explicitly separating the<br>
> tests is more friendly for new users.<br>
<br>
</div></div>Let me cite from the blueprint for the reasons:<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
Reorganize the gating setup to combine the tiny jobs into a single<br>
voting and a single non-voting check. This will give more flexibility in<br>
adding new jobs and reduce load of Jenkins.<br>
Problem description<br>
<br>
Most of the current jobs are very small and it takes far longer to setup<br>
the virtual environment than running the tests. For example the niceness<br>
check runs in two seconds - while Jenkins needs at least 3 minutes for<br>
the whole job. The difference is that Jenkins needs to start a new<br>
virtual machine, install the git repository and all packages.<br>
<br>
With the addition of checking for links, we would have the following<br>
tiny jobs where each normally runs in less than 2 seconds:<br>
<br>
    niceness check<br>
    syntax check<br>
    deletions check<br>
    linked URL check<br>
<br>
Let’s combine these tiny jobs into voting and non-voting jobs.<br>
<br>
This gives us also the flexibility to add additional jobs easily and<br>
decide per repository on which of these jobs are voting and which are<br>
non-voting.<br></blockquote><div><br></div><div>I'm catching up. My first thought is that it's a bit different from what the rest of the teams are doing, and I wondered if this is a test bed for other projects? I know when I do a patch for nova the list of pass/fail is long. It might be nice from a usability standpoint to pre-sort the list in voting, non-voting (and for nova, 3rd party). Is that what spurred this blueprint? It's a bit out of the blue (ha) so just trying to get context.</div>

<div><br></div><div>Thanks,</div><div>Anne</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
<br>
The flexibility and the reduced work load are nice - but indeed this is<br>
nothing we have to change.<br>
<br>
That's why I wanted the discussion - to weight the pros and cons.<br>
<span class="HOEnZb"><font color="#888888"><br>
Andreas<br>
--<br>
 Andreas Jaeger aj@{<a href="http://suse.com" target="_blank">suse.com</a>,<a href="http://opensuse.org" target="_blank">opensuse.org</a>} Twitter: jaegerandi<br>
</font></span><div class="im HOEnZb">  SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany<br>
   GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg)<br>
    GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Openstack-docs mailing list<br>
<a href="mailto:Openstack-docs@lists.openstack.org">Openstack-docs@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs</a><br>
</div></div></blockquote></div><br></div></div>