[Ksummit-2013-discuss] [ATTEND] static checking; COMPILE_TEST

[Julia Lawall]

On Sun, 21 Jul 2013, Jiri Slaby wrote:

> On 07/19/2013 05:55 PM, Dan Carpenter wrote:
> > On Fri, Jul 19, 2013 at 11:21:01AM +0200, Jiri Slaby wrote:
> >> Yes, this is exactly my point. There are outputs of analyzers (I give
> >> coverity as an example), but maintainers ignore those (one random
> >> example is at [1]). Then people which do not understand the code well
> >> enough, come up with fixes which are inappropriate.
> >
> > These days Fengguang will send a warning to the person who
> > introduces the bug as soon as it shows up on a public git tree.
> > He does GCC warnings, Sparse, and Coccinelle.  I do the same for
> > Smatch warnings.  If you warn the right people while the code is
> > still fresh in their mind then it tends to get fixed.
>
> Well, I am talking about full featured checkers/analyzers/model checkers
> which take a fair amount of time to execute on the kernel. There is no
> option to run them on a per commit basis and inform the commit authors
> about introduced errors.
>
> These tools are usually run weekly/monthly and the results are made
> available. On some kind of web interface with email notification sent to
> the list. It is very hard to present the errors in an email as mostly
> these error reports are useless without traces due to their complexity.
> Yeah, the frontends might look complicated, but I do not find them so
> hard to use.
>
> Nonetheless the reports are often ignored (see my other mail) despite
> they contain severe error reports.

Would it help to somehow automatically send the message again when a
commit on the file appears?  Then at least someone was recently thinking
about the code, even if it was about some completely different aspect, and
that person might be willing to spend a little time on the problem?

julia