+1 I hate putting one line changes in JIRA On Sat, Jul 7, 2012 at 5:24 PM, Gabriel Reid <[email protected]> wrote:
> +1. Sounds pragmatic (and therefore good) to me. > > On 07 Jul 2012, at 18:02, Josh Wills <[email protected]> wrote: > > > 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> > -- Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/
