| |||||||||||||
Introducing the "Debian's Automated Code Analysis" (DACA) projectIntroducing the "Debian's Automated Code Analysis" (DACA) projectPosted Dec 16, 2010 23:19 UTC (Thu) by MisterIO (guest, #36192)Parent article: Introducing the "Debian's Automated Code Analysis" (DACA) project
cppcheck is 2 releases old in debian(months old) and they're gonna use it to check the packages? It's probably better to start maintaining it better then.
(Log in to post comments)
Introducing the "Debian's Automated Code Analysis" (DACA) project Posted Dec 16, 2010 23:20 UTC (Thu) by MisterIO (guest, #36192) [Link]
And I'm talking about sid|experimental obviously.
Introducing the "Debian's Automated Code Analysis" (DACA) project Posted Dec 17, 2010 0:24 UTC (Fri) by naoliv (subscriber, #21066) [Link]
Well... why not help us then? ;-)
Introducing the "Debian's Automated Code Analysis" (DACA) project Posted Dec 17, 2010 1:37 UTC (Fri) by MisterIO (guest, #36192) [Link]
There's still version 1.44 probably because of the freeze for v6.0 release(I've seen that answer to many bug reports(whishlist) asking to upgrade a package), so probably lack of help isn't the problem here. Why exactly does the freeze include sid+experimental, I don't know. Or maybe, simply because there's the freeze,the maintainer isn't interested in updating the package, even if in sid|experimental it's permitted, I'm not sure. Valgrind too is an svn snapshot, when the official release is already out. Clang is months old too. The gcc suite is well maintained instead.
Introducing the "Debian's Automated Code Analysis" (DACA) project Posted Dec 17, 2010 4:40 UTC (Fri) by tao (subscriber, #17563) [Link]
The freeze doesn't include experimental (so packages in experimental can still be freely upgraded), but it does include sid. This is because unstable is the staging ground for packages that enters testing.
Using experimental is not very common though (neither among developers nor among users), since it's not a complete distribution (which unstable is), only a partial repository (if it was a complete distribution it wouldn't be possible to cherry pick from experimental, because of dependencies).
The fastest way to ensure that new versions of cppcheck gets integrated in unstable at a timely manner is to help get Debian 6.0 out of the door, so if you feel like you can help fix any of the open RC-bugs, please do.
Of course, playing the Devil's Advocate it's likely that extensive testing of the packages in the archive with cppcheck might actually increase the number of RC bugs, in case it uncovers a lot of severe bugs. But that's flawed reasoning...
Introducing the "Debian's Automated Code Analysis" (DACA) project Posted Dec 20, 2010 19:37 UTC (Mon) by k8to (subscriber, #15413) [Link]
The freeze of sid leading up to a release is pretty annoying. I think as a project management issue it's pretty important though, if you believe in the value of a stable release. You have to have a stick that makes it unavoidably important to stabilize your continuous development line if you want to release a relatively unchanging version that you keep working for years.
Personally, I don't give a rats ass about the stable releases, and would rather use a continuously updated (but tested) set of packages than an unchanging one. But I have actually met people who use stable on their servers and appreciate what it is.
Project management is full of compromises.
Introducing the "Debian's Automated Code Analysis" (DACA) project Posted Dec 17, 2010 0:30 UTC (Fri) by tao (subscriber, #17563) [Link]
So you're saying that version 1.44 of cppcheck was a totally useless tool then?
FWIW, cppcheck 1.46 was release 2 days ago.
Also, Debian is in freeze pending the upcoming 6.0 release.
Introducing the "Debian's Automated Code Analysis" (DACA) project Posted Dec 17, 2010 1:07 UTC (Fri) by xxiao (subscriber, #9631) [Link]
why use cppcheck instead of splint? my first time to hear about cppcheck, did a quick run, and it reports a few errors in my code, looks like it's pretty helpful.
Introducing the "Debian's Automated Code Analysis" (DACA) project Posted Dec 18, 2010 17:25 UTC (Sat) by ballombe (subscriber, #9523) [Link]
I found that cppcheck sound/noise ratio was much better than splint on C code that was not prepared to be run through splint. I did not try C++.
Introducing the "Debian's Automated Code Analysis" (DACA) project Posted Dec 17, 2010 1:27 UTC (Fri) by MisterIO (guest, #36192) [Link]
When did I say that 1.44 was useless?
Introducing the "Debian's Automated Code Analysis" (DACA) project Posted Dec 17, 2010 4:31 UTC (Fri) by tao (subscriber, #17563) [Link]
This is the message I replied to:
"cppcheck is 2 releases old in debian(months old) and they're gonna use it to check the packages? It's probably better to start maintaining it better then."
While my interpretation of your statement was hyperbole, you have to admit that your comment was borderline trollish.
Instead of questioning the use of anything less than the latest release of cppcheck (if you look at the release date, I think that you'll find that even cppcheck 1.45 was released after Debian was frozen), why not simply state that "There's now an even newer and better version of cppcheck available from upstream" or similar.
And, as another poster already said, I'm sure any effort to help packaging it for experimental or for that matter to fix the cppcheck related bugs in BTS would be appreciated.
Introducing the "Debian's Automated Code Analysis" (DACA) project Posted Dec 20, 2010 19:41 UTC (Mon) by k8to (subscriber, #15413) [Link]
I think the general expectation from some users is that the distribution is a means to conveniently track upstream releases. When this expectation is not fulfilled, it's perceived as a problem. I don't think this expectation is really fundamentally unreasonable, but it does conflict with some other goals. From this conflict and the gap in behavior, gaps between perception and reality arise, and thus criticism.
Introducing the "Debian's Automated Code Analysis" (DACA) project Posted Dec 22, 2010 10:40 UTC (Wed) by liljencrantz (subscriber, #28458) [Link] I must confess to disagree with pretty much every opinion in your entire post. :-(
Introducing the "Debian's Automated Code Analysis" (DACA) project Posted Dec 22, 2010 17:05 UTC (Wed) by k8to (subscriber, #15413) [Link]
Your view of users is too simplistic. Some expect blissful functionality. Some expect currentness. Some expect both. A significant number don't think too much about the conflicts here.
I was just talking about the trend or set who expect currentness, almost implicitly.
So you aren't actually disagreeing with me at all.
Introducing the "Debian's Automated Code Analysis" (DACA) project Posted Dec 17, 2010 3:46 UTC (Fri) by geissert (subscriber, #61258) [Link]
I don't want to kill the discussion, but picking a (not-so) random results page[1]:
"This report was generated on Thu, 16 Dec 2010 04:03:51 +0000, based on results by cppcheck 1.46"
[1] http://qa.debian.org/daca/cppcheck/sid/apache2_2.2.16-4.html
Cheers
Introducing the "Debian's Automated Code Analysis" (DACA) project Posted Dec 17, 2010 7:42 UTC (Fri) by MisterIO (guest, #36192) [Link]
That's ironic!
Introducing the "Debian's Automated Code Analysis" (DACA) project Posted Dec 17, 2010 12:44 UTC (Fri) by mgedmin (subscriber, #34497) [Link]
That's a nice page!
Any chances of having the filenames + line numbers be actual hyperlinks to the source code, for a convenient closer look?
Introducing the "Debian's Automated Code Analysis" (DACA) project Posted Dec 18, 2010 20:30 UTC (Sat) by geissert (subscriber, #61258) [Link]
At the moment Debian doesn't have such service and the web reports are generated directly from the tool's report on a machine other than the one that actually ran the tool, making it impractical.
I'm not even sure if those working on the source.d.o project intended to provide HTML-ised source code (with lxr or the like.)
I do agree that it would be a great feature to have and is even in my long term To-Do list, though.
Introducing the "Debian's Automated Code Analysis" (DACA) project Posted Dec 20, 2010 23:17 UTC (Mon) by NightMonkey (subscriber, #23051) [Link]
I'm sure your team knows about this, but the included (at least in the source package) htmlreport will generate in-line source code. I use it to make a full report on LibreOffice's git code every 4-6 hours, for their dev's benefit:
http://libreoffice.boldandbusted.com/
DO NOTE: This is a huge report. Your browser may creak under the strain.
Big thanks to cppcheck! :)
Introducing the "Debian's Automated Code Analysis" (DACA) project Posted Dec 21, 2010 2:01 UTC (Tue) by geissert (subscriber, #61258) [Link]
I'm aware of it (and have even used it locally for some projects.) However, like I replied to people who suggested it via email, DACA doesn't consist of only one tool, and all of them would benefit from a service that provides the html-ised source code with anchors and all.
Introducing the "Debian's Automated Code Analysis" (DACA) project Posted Dec 17, 2010 17:47 UTC (Fri) by jthill (guest, #56558) [Link] Ouch. I sure hope they didn't do signoffs back in 2004 (specifically r109623), those are blatant. I notice it didn't flag the unchecked malloc returns.
|
|||||||||||||