We now have a few years and releases of LibreOffice behind us, thus our bugzilla data should be in an acceptable state to maybe gain some insight in the areas where we are most likely to regress.
This EasyHack suggests to:
- query and collect bugs marked as regressions on bugzilla
- then find the corresponding commits on git
- count by how many regression-fix-commits each directory was touched.
This might allow us to focus our attention on the critical areas for writing unit tests and get our coverage up in that area first:
I renamed that 2nd link mentioned, so that the git commit SHA1 is part of the name (so you can tell on what revision the report was run). So the 2nd link mentioned above is no longer valid. Ooops.
Look here instead: http://dev-builds.libreoffice.org/lcov_reports/master~2013-07-08_14.53.51_commit-3a393557152ec61ebfe75580db0a2e321febfda3/
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.
see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
done with http://cgit.freedesktop.org/libreoffice/contrib/dev-tools/commit/?id=fc7dcf4ebef84c66f59f7188d02c8706a0993b51
script is at:
it currently takes ~200 minutes to run completely.
One note -- it is still buggy in that git log --stat prints incomplete filepaths a la ..../foo/baz.cxx if the filename is too long, but it already gives a good hint on the hotspots.
(In reply to comment #3)
> it currently takes ~200 minutes to run completely.
Could you make available the output (or the top N lines of output), so one gets an idea what that looks like in under 200 minutes?
see follow-up Easy Hack 70448:
Migrating Whiteboard tags to Keywords: (EasyHack SkillScript DifficultyBeginner)
Remove LibreOffice Dev List from CC on EasyHacks
(curtailing excessive email to list)