--On Wednesday, January 18, 2006 5:46 PM -1000 Aaron Kagawa
<[EMAIL PROTECTED]> wrote:
I've been using the JIRA-Subversion plugin for a while now and its been
working out good. At the very least its nice to see a historical record
of all the commits I've done to complete a Jira issue. I've been
thinking about how to integrate this extra information into the Jira
sensor, but haven't really taken any action on that. It could be
interesting to see the number of commits, the code churn, the number of
files, etc, to complete an issue. What does it mean when "Major" issue
that take 1 commit of 20 lines of code and a "Minor" issue takes 5
commits of 1 line of code? Or is that even interesting at all?
Jeez, I dunno. Maybe it means the "Major" issue was really minor and the
"Minor" issue was really major!
* Instead of chucking the remaining issues into 7.3, I made them all
version-less.
This a good idea as long as we don't "forget" about going through the
version-less issues and assigning them to a version later on.
Yes, I agree. My new strategy is to always go through all of the
version-less issues at the beginning
of a new stable release cycle, so that all extant issues get reviewed
occasionally.
A while ago I proposed a simple alert that should be able to identify
workspaces that you have active time for but do not have a "matching"
jira issue. This alert would be as accurate as the Jira workspaces field,
but with the Jira-Subversion plugin could help with this matching as well.
Interesting idea! Cedric may want to reflect on this for his research.
Cheers,
Philip
