crunch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabriel Reid <gabriel.r...@gmail.com>
Subject Re: Granularity of information in JIRA
Date Sat, 07 Jul 2012 16:24:33 GMT
+1. Sounds pragmatic (and therefore good) to me. 

On 07 Jul 2012, at 18:02, Josh Wills <jwills@cloudera.com> 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 <gabriel.reid@gmail.com> 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>

Mime
View raw message