On Wed, Jul 3, 2013 at 10:57 AM, Michael Blumenkrantz <
michael.blumenkra...@gmail.com> wrote:

> On Wed, Jul 3, 2013 at 2:44 PM, Gustavo Sverzut Barbieri <
> barbi...@profusion.mobi> wrote:
>
> > On Wed, Jul 3, 2013 at 10:00 AM, Carsten Haitzler <ras...@rasterman.com
> > >wrote:
> >
> > > On Wed, 03 Jul 2013 13:42:22 +0100 Stefan Schmidt <
> s.schm...@samsung.com
> > >
> > > said:
> > >
> > > > Hello.
> > > >
> > > > On 07/03/2013 11:48 AM, Stefan Schmidt wrote:
> > > > >
> > > > > If you want to have a look and help us fixing bugs or marking
> things
> > as
> > > > > false positive please register at scan.coverity.com and request
> > access
> > > > > to these projects. Daniel or myself can then approve your access
> and
> > > you
> > > > > can have a look.
> > > > >
> > > > > efl: http://scan.coverity.com/projects/552
> > > > > elm: http://scan.coverity.com/projects/553
> > > > > e:   http://scan.coverity.com/projects/554
> > > >
> > > > Some numbers:
> > > >
> > > > EFL: 521,687 lines of code and an initial set of 559 defects results
> in
> > > > a defect density of 1.07. 1.0 is what they rate as industry standard
> > and
> > > > means 1 defect in thousand lines of code.
> > > >
> > > > Elm has 210,048 but only 77 initial defects resulting in a way lower
> > > > defect density of 0.37.
> > > >
> > > > E is a middleground with 273,355 lines of code and 205 initial
> defects
> > > > resulting in a defect density of 0.75.
> > > >
> > > > All in all that looks quite ok to me. I suspect some false positives
> in
> > > > efl especially in the way we use eina_list and hash and take care
> about
> > > > resource free'ing.
> > > >
> > > > regards
> > > > Stefan Schmidt
> > >
> > > i'd say that pretty damned good... considering. i think we may be a bit
> > > harsh
> > > on ourselves at times...
> > >
> > > BUT WE SHOULD BE! industry average is not good enough! :) m(elm is
> > > surprising
> > > btw! - same with e. i would have expected efl is better).
> > >
> >
> > that confirms that coverity tool is clearly bogus AND elm has too much
> > lines of code in it (that does nothing, like 5 lines per callback
> function,
> > or more  such as static\nname_cb(void *data)\n{\nNameType *t;\n t =
> > data;\n...\n}\n) :-D
> >
> > --
> > Gustavo Sverzut Barbieri
> > http://profusion.mobi embedded systems
> > --------------------------------------
> > MSN: barbi...@gmail.com
> > Skype: gsbarbieri
> > Mobile: +55 (19) 9225-2202
> >
>
> but if there weren't so many lines of code, how would any of us reach our
> management evaluation objectives?
>

true, would also make hard to justify 100k commits to cleanup whitespaces!

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to