From: Paolo Bonzini <pbonzini@redhat.com>
To: "Philippe Mathieu-Daudé" <f4bug@amsat.org>,
"Peter Maydell" <peter.maydell@linaro.org>,
qemu-devel@nongnu.org
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
"Markus Armbruster" <armbru@redhat.com>,
patches@linaro.org, "Fam Zheng" <famz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 1/3] travis: install more library dependencies
Date: Wed, 14 Jun 2017 18:49:05 +0200 [thread overview]
Message-ID: <7de47a0f-baad-d849-eebd-87c86dae16c1@redhat.com> (raw)
In-Reply-To: <7b7e4b38-923d-b928-ab09-716b2140273b@amsat.org>
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
next prev parent reply other threads:[~2017-06-14 16:49 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-13 15:54 [Qemu-devel] [PATCH 0/3] Automate coverity scan uploads via Travis Peter Maydell
2017-06-13 15:54 ` [Qemu-devel] [PATCH 1/3] travis: install more library dependencies Peter Maydell
2017-06-14 3:52 ` Philippe Mathieu-Daudé
2017-06-14 15:07 ` Paolo Bonzini
2017-06-14 15:37 ` Philippe Mathieu-Daudé
2017-06-14 16:49 ` Paolo Bonzini [this message]
2017-06-14 17:04 ` Peter Maydell
2017-06-14 17:20 ` Paolo Bonzini
2017-06-29 14:37 ` Peter Maydell
2017-06-14 14:45 ` Alex Bennée
2017-06-14 15:15 ` Daniel P. Berrange
2017-06-14 15:25 ` Philippe Mathieu-Daudé
2017-06-13 15:54 ` [Qemu-devel] [PATCH 2/3] scripts/run-coverity-scan: Script to run Coverity Scan build Peter Maydell
2017-06-14 15:01 ` Alex Bennée
2017-06-29 16:12 ` Eric Blake
2017-06-29 16:15 ` Peter Maydell
2017-06-13 15:54 ` [Qemu-devel] [PATCH 3/3] travis: Add config to do a Coverity Scan upload Peter Maydell
2017-06-14 15:14 ` Alex Bennée
2017-06-14 15:46 ` Peter Maydell
2017-06-13 16:15 ` [Qemu-devel] [PATCH 0/3] Automate coverity scan uploads via Travis no-reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7de47a0f-baad-d849-eebd-87c86dae16c1@redhat.com \
--to=pbonzini@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=armbru@redhat.com \
--cc=f4bug@amsat.org \
--cc=famz@redhat.com \
--cc=patches@linaro.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.