Re: RFS: cppcheck, new upstream version 1.31
On Sunday 12 April 2009 23:09:42 Reijo Tomperi wrote:
> George Danchev wrote:
> > On Sunday 12 April 2009 21:45:04 Reijo Tomperi wrote:
> >> Reijo Tomperi wrote:
> >>> Dear mentors,
> >
> > Hi,
> >
> >> The package can be found on mentors.debian.net:
> >> - URL: http://mentors.debian.net/debian/pool/main/c/cppcheck
> >> - Source repository: deb-src http://mentors.debian.net/debian unstable
> >> main contrib non-free
> >> - dget
> >> http://mentors.debian.net/debian/pool/main/c/cppcheck/cppcheck_1.31-1.ds
> >>c
> >
> > I checked the latest cppcheck source with the latest binary of cppcheck
> > (as built out of it), and these look like false positives:
> >
> > [./gui/resultsview.h:66]: (all) Memory leak: ResultsView::mTree
> > [./gui/resultsview.h:72]: (all) Memory leak: ResultsView::mProgress
> > ...
> > [./gui/settingsdialog.h:100]: (all) Memory leak: SettingsDialog::mJobs
> > ...
> > [./src/tokenize.h:209]: (all) Memory leak: Tokenizer::_tokens
> >
> > Surely there is something to fix here; either the mysterious memory leaks
> > or their detection ;-)
>
> Thanks, but we know about those already, which is why those checks are
> behind the --all switch (our dirty and easy escape from false positives).
>
> cppcheck --help
>
> Options:
> -a, --all Make the checking more sensitive. More bugs are
> detected, but there are also more false positives
Yes, you are correct.
> But perhaps the error text should be changed to something more
> revealing. I made a ticket about it:
> http://apps.sourceforge.net/trac/cppcheck/ticket/251
>
> But these are not regression bugs, they have been there for quite some
> time.
A proper error message would be nice.
I uploaded 1.31 package to sid.
> >> ps. No upstream changelog yet with this release, sorry. Still trying to
> >> figure out what it should look like (different projects seem to have
> >> different ideas about that) and how to generate it in upstream release.
> >
> > Maybe you would like to test git2cl [1] a bit.
> >
> > [1] http://josefsson.org/git2cl/README
>
> Thanks again, but the question is more about whether we should use git
> logs, or ticket list (of closed tickets), or just the short summary we
> put in sourceforge news page. Not really sure what people would prefer
> to see. That probably depends on what they are looking for.
>
> Most common seems to be full list of git logs, similar to what that tool
> produces. But is that what people really want?
We can't be easily sure what really people want unless we start with some sort
of upstream changelog. OTOH, policy 12.7 does not mandate a mandatory upstream
changelog, but providing one would be nice like most of other packages do.
Also GNU changelog standards (as produced by cvs2cl, git2cl, etc) could hardly
be unexpected or unknown to the users, though I'm not sure if they could be
classified as boring.
--
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>
Reply to: