Kathey Marsden [W.P.A YELLOW PAGES] wrote:
I was thinking about Derby Metrics.
I think this is a good initiative Kathey, having metrics like these in
place would be useful when discussing releases and quality.
1) Has anyone compiled any of the following information already?
2) Can you think of additonal metrics that might be useful to the
community?
The size of jar-files might be useful to measure/monitor (when compiled
with the right flags and options that are used for releases). The intent
would be to have awareness on the small, light-weight image.
In addition to measuring lines of code added or total, I've also heard
about measuring the number of lines of code that have been changed
(added/removed/updated), loosely refered to as measuring "code turmoil".
With a lot of code turmoil you expect less stability, this number should
go down when you get close to a release.
Derby lines of code by component.
Derby code coverage numbers by component.
Lines of code added for 10.2 by component.
Derby bugs by component and severity.
Derby bug inflow by component and overall.
Did you plan to do this as a one shot exercise or did you want to do it
periodically, like daily or weekly? I think weekly numbers would be
good, would be often enough and might mask uninteresting fluctuations
that you might see if producing daily numbers.
Vemund
