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

[Paolo Bonzini <pbonzini@redhat.com>]

On 14/06/2017 19:04, Peter Maydell wrote:
> On 14 June 2017 at 17:49, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> 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.
> 
> Yes, I overall agree that we maybe don't want to use Travis
> for this, but I would like us to automate it somehow.
> (I was about 50/50 on whether to tag the patchset as RFC.)
> 
>> 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
> 
> Yes, but this one (I think) only happened because I got fed
> up enough of the build being out of date to go and find out
> how to rebuild it and do an upload. I think I also did the
> 1st June one by hand, maybe?

Yes, that one I was super-busy (and travelling until April 16).  On June
1 and June 12 we crossed, you did one at the same time as me but you
must have faster internet uplink (not hard :)).

> I'm more likely to look at coverity during freeze periods
> than less, because bugs coverity notices are more likely
> than not to be candidates for being worth fixing before
> releases, and I don't have my plate full with feature work.
> So I'd rather have the build be as up to date as possible
> during a release so we can catch any bugs that snuck in
> before we hit the last release candidate.

Understood, on the other hand during freeze periods it's easier to look
at what went in and see how safe it is.

> Conversely, if we don't do scans very frequently then the
> "outstanding defects" view gets hard to use because it's
> still showing things we've already fixed and isn't showing
> new things we've introduced but not scanned yet.
The beauty of doing manual scans is that you can do them when that pull
request with lots of Coverity fixes has just gone in. :)  Seriously, I
didn't think frequency was a problem and we must have different
workflows.  I rely more on "all newly detected"/"all newly fixed" than
on the "new" state, because that can more easily show problems in the
build environment, though admittedly a more reproducible scan recipe
makes that less relevant.

Paolo