Re: [Qemu-devel] [PATCH 1/3] travis: install more library dependencies

[Paolo Bonzini]

On 14/06/2017 17:37, Philippe Mathieu-Daudé wrote:
> On 06/14/2017 12:07 PM, Paolo Bonzini wrote:
>>
>>
>> On 14/06/2017 05:52, Philippe Mathieu-Daudé wrote:
>>> As you said, due to Travis using Ubuntu still not all libs get detected
>>> but at least the following:
>>>
>>>  $ ./configure ${CONFIG}
>>> -VirtFS support    no
>>> +VirtFS support    yes
>>> -bluez  support    no
>>> +bluez  support    yes
>>> -xfsctl support    no
>>> +xfsctl support    yes
>>> -lzo support       no
>>> +lzo support       yes
>>> -snappy support    no
>>> +snappy support    yes
>>>
>>> Using debian based docker images on Shippable we also get:
>>>
>>> -nettle            no
>>> -nettle kdf        no
>>> +nettle            yes (3.3)
>>> +nettle kdf        yes
>>> -rbd support       no
>>> +rbd support       yes
>>> -vde support       no
>>> +vde support       yes
>>> -GlusterFS support no
>>> +GlusterFS support yes
>>> -libnfs support    no
>>> +libnfs support    yes
>>
>> So this leaves out only rdma and iscsi?
>>
>> I don't know travis vs. shippable very well, can you provide a similar
>> patch to shippable?
> 
> Travis base images are Ubuntu based, as said Peter "some of our
> dependencies need versions that are closer to the bleeding edge than
> those distros provide".

Well, trusty is 3 years old by now... I wouldn't call that bleeding
edge, and it seems like Travis is suggesting using Docker images for
those who want to use a newer distro.  This patch and patch 2 are
useful, but I think I'd rather get full coverage, either with Shippable
or by keeping on doing manual builds, than to rush things and switch to
CI when it's not ready.

First, I don't think it's accurate to say that scans have been often
weeks or months apart:

                        #days   #commits
        2017-06-05      4       123
        2017-06-01      14      214
        2017-05-18      3       108
        2017-05-15      8       262
        2017-05-07      12      149
        2017-04-25      24      317
        2017-04-01      4        47
        2017-03-28      7        86
        2017-03-21      4        35
        2017-03-17      1        29
        2017-03-16      2       107
        2017-03-14      5        42
        2017-03-09      0       180
        2017-03-09      6         0     (updated model file)
        2017-03-03      4       347
        2017-02-27      6       198
        2017-02-21      1        62
        2017-02-20      0        69
        2017-02-20      4         0     (updated model file)

Until Coverity bumped the maximum frequency of builds, we were doing
scans pretty much as fast as we were allowed to (1 per week I think):

        2017-02-16      13      148
        2017-02-03      9       298
        2017-01-25      7       283
        2017-01-18      14      464
        2017-01-04      49      230
        2016-11-16      9       275
        2016-11-07      14      504
        2016-10-24      14      243
        2016-10-10      10      190
        2016-09-30

In the last eight months, there was exactly one case where the builds
were more than one month apart and one more case where the builds were
more than two weeks apart.  Both of them coincided with the two most
recent hard freeze periods (2.8 and 2.9).

Second, I don't even think that CI is particularly useful when someone
must actively consume those scans: triage newly-reported defects, inform
the authors of the patch, and so on.  Too many Coverity reports can be a
burden because you cannot use e.g. the "All newly detected" view.

Of course I'm all for making Coverity builds more accessible to people
with the project token, through better scripts and possibly integration
with the Docker testing targets.

Paolo