I have the same thought-- for example, I put in a commit yesterday that swapped thirdparty.guava -> com.google.common everywhere we were using it (which was ~2 lines). It didn't seem big enough for a JIRA, so I just put it in.
I think my rule of thumb is something should have a JIRA if there is a reasonable question that notifying everyone else about it would be a good idea before it was put in to the system. Some combination of: 1) Bug fixes should always be in JIRA so that we can reference them, 2) The change will alter functionality in some way, 3) or the change involves touching more than 10 lines of code. Thoughts? On Sat, Jul 7, 2012 at 2:25 AM, Gabriel Reid <[email protected]> wrote: > Hi guys, > > I was wondering if anyone has any thoughts on the granularity of > information we want to keep in JIRA -- that is, should every commit in git > start from a linked JIRA issue from now on? > > For a specific example, I was going to add a log4j.properties file to > src/test/resources to provide more detailed logging for Hadoop tasks (to > make it easier to see what's going wrong when something crashes in the > local job runner). I was just doubting whether or not I should log this in > JIRA first, or just commit it. > > I'm ok either way we go with this, but I just want to be sure I'm not > rocking the boat if there are implicit conventions on this (or explicit > conventions that I don't know about). > > Gabriel -- Director of Data Science Cloudera <http://www.cloudera.com> Twitter: @josh_wills <http://twitter.com/josh_wills>
