i can't say for tizen 3 or prevent, as tizen is in a bit of a strange
position. it is both a distribution AND a duplicate of upstream projects
AND a set of independently developed software projects... but upstream
EFL has our trees for efl, elementary and enlightenment registered with
coverity scan (for about 6 months now). coverity allows any open source
project to apply to hav e them scan the project code for free (they do
it once per day and you can register a git tree that they will update from).
according to coverity, industry standard for "good quality commercial
code" is 1.0 coverity found bugs per 1000 lines of code. the linux
kernel comes in at about 0.6 or so (depending on version). postgresql
was about 0.2. open source projects shows better average code quality
than commercial projects. as commercial projects became bigger their
quality went down (issues per 1000 lines of code went up - thus as a
precentage of code size, bugs increased faster than code size did). open
source projects show the reverse trend. as they get bigger, their
quality increases (issues per 1000 lines of code goes down).
we've been using coverity to improve efl codebase quality. currently our
bugs per 1000 lines of code are:
efl: 0.60
elementary: 0.11
enlightenment: 0.66
these numbers have been steadily going down over the past 6 months as
we've gone over the coverity reports and nuked the issues they do find.
we've also been using clang's static analysis too. we are also fairly
religious about keeping the code gcc "warning free" (given a relatively
noisy set of warning flags like -W -Wall -Wextra -Wno-shadow
-Wno-unused-but-set-parameter). it's a bad idea to use just one tool. so
even if you don't see prevent output, there are other options to look at
for automatid quality checking tools.
we'd like to see out issue densities get to as close to 0 as possible.
:) i know that coverity scanning is not finding the kinds of bugs that
are "i press button and it doesnt do what it should" kind of bugs, but
they do hunt down often the "very rare and mostly invisible" bugs that
happen in bizarre code paths that are hard to reproduce and may be the
"happens only once" kind of bug reports. the advantage is that coverity
provide a REALLY good indicator of where the bug is and a trace of why
it happens. it's far less obscure than clang reports. clan is free+open
and can only help in improving quality. many things clang finds are
things coverity (and prevent) look for too. look at
https://build.enlightenment.org/job/nightly_efl_clang_x86_64/lastSuccessfulBuild/artifact/scan-build/build/2013-12-12-1/index.html
for example (we run nightly clang reports too on upstream code).
if the code you work on is an open source project with an upstream,
consider registering for a free coverity scan. they have a web ui for
going through the issues etc. etc. which is not that bad at all (it's
pretty good actually). reality is that if the upstream project is then
used in tizen, tizen totally benefits from the better code quality right
out of the box. and you can use clang today for free to do the same.
On 12/12/2013 09:06 PM, Nikita Kalyazin wrote:
Hello,
As far as I know, there was some automatic Prevent check for Tizen 2.1 projects.
Does such a service exist for Tizen 3.0? If so, what is the subscription
procedure for that?
Thank you.
--
The above message is intended solely for the named addressee and may
contain trade secret, industrial technology or privileged and
confidential information otherwise protected under applicable law
including the Unfair Competition Prevention and Trade Secret Protection
Act. Any unauthorized dissemination, distribution, copying or use of the
information contained in this communication is strictly prohibited. If
you have received this communication in error, please notify the sender
by email and delete this communication immediately.
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
