Introducing the "Debian's Automated Code Analysis" (DACA) project [LWN.net]

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. :-(

I don't think users expect distributions to track upstream releases, I think users expect the distributions to put together a set of software that works well together. Sometimes that implies keeping an unstable release back (KDE4.[012]), on rare occasions it means distributing unreleased betas that actually work better than the latest stable release (Emacs).
I think that to the extent users have this expectation, it is fundamentally completely and utterly unreasonable. A distribution needs to consist of packages that work well together. When the latest version of package X switches to a new API, and the critical system package Y uses the API of package X but has not yet been updated to the new API, I think there is a strong expectation that the distribution doesn't jump in and release a new X package and making Y useless.

The above is in complete conflict with the idea of tightly tracking the latest release of upstream, and if a user expects this, informing the users of why his/her expectations are unreasonable is the right course of action, not criticizing the distribution.

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.