Open Stack

I think we can still consider the middle-ground, where only deprecated 
multinode jobs, which tripleo infra team is in progress of migrating 
into standalone jobs, could be made depending on unit and pep8 checks? 
And some basic jobs will keep being depending on nothing.

I expanded that idea in WIP topic [0]. Commit messages explain how the 
ordering was reworked.

PS. I'm sorry I missed the submitted stats for zuul projects posted 
earlier in this topic, I'll take a look into that.

[0] 
https://review.openstack.org/#/q/topic:ci_pipelines+(status:open+OR+status:merged)

> Bogdan Dobrelya <bdobreli at redhat.com> writes:
>> On 26.02.2019 17:53, James E. Blair wrote:
>>> Bogdan Dobrelya <bdobreli at redhat.com> writes:
>>> 
>>>> I attempted [0] to do that for tripleo-ci, but zuul was (and still
>>>> does) complaining for some weird graphs building things :/
>>>>
>>>> See also the related topic [1] from the past.
>>>>
>>>> [0] https://review.openstack.org/#/c/568543
>>>> [1] http://lists.openstack.org/pipermail/openstack-dev/2018-March/127869.html
>>> 
>>> Thank you for linking to [1].  It's worth re-reading.  Especially the
>>> part at the end.
>>> 
>>> -Jim
>>> 
>>
> 
> Yes, the part at the end is the best indeed.
> I'd amend the time priorities graph though like that:
> 
> CPU-time < a developer time < developers time
> 
> That means burning some CPU and nodes in a pool for a waste might 
> benefit a developer, but saving some CPU and nodes in a pool would 
> benefit *developers* in many projects as they'd get the jobs results off 
> the waiting check queues faster :)



-- 
Best regards,
Bogdan Dobrelya,
Irc #bogdando