But what actual value do these JIRAs add? What is the benefit that the git log message doesn't provide?
On Thu, Jan 7, 2016, 09:54 Josh Elser <[email protected]> wrote: > I think I disagree that they are a lot of work or a big distraction. > > The amount of work behind a trivial change (in terms of the tool: git) > is no different (you commit to all active branches and maybe fix merge > conflicts). > > Personally, I find little nit-picky things good to just piggy-back on > the original JIRA they were introduced in. For "old" issues (where the > original change are long dead or the changes were in the initial > import), I'd rather see a #2 as below. The reasoning is that if I have > merge conflicts, I can at least see that it was only formatting changes > (and not some functionality change). > > If there are things you believe are worth fixing, they are by definition > not a distraction. > > Overall, I think it's a non-issue, but, when encountering this: > "reasonable" amounts of batching of trivial changes would be nice (#2). > > Christopher wrote: > > Accumulo Devs, > > > > We typically create a JIRA for every change, and then explicitly > reference > > that JIRA in the git commit log. Sometimes, this seems like a lot of work > > (or, at the very least, a big distraction) for *really* trivial > changes[1]. > > > > My question(s): > > > > What are the pros and cons of being strict about this for trivial issues? > > What value does creating a JIRA actually add for such things? Is the > > creation of a JIRA issue worth the distraction and time in ALL cases, or > > should developer discretion apply? How strict to we want to be about JIRA > > references? > > > > * * * > > > > For additional consideration, I've noticed that trivial fixes tend to get > > addressed in the following ways: > > > > 1. "Drive-by" - rolled into another, unrelated, commit (will get > > reviewed/reverted/merged along with a non-trivial issue, simply due to > its > > vicinity in space or time) > > 2. "One-JIRA-to-rule-them-all" - a JIRA without much of a description, > > created "just so we have a ticket to reference" for several (perhaps > > unrelated) trivial fixes > > 3. "One-JIRA-each" - each trivial issue gets its own JIRA issue, its own > > commit, and its own description (many of each are nearly identical) > > > > In each case, it seems like it would have been sufficient to simply > > describe the trivial change in a separate git commit which is included in > > the next push. > > > > * * * > > > > [1]: By "*really* trivial changes", I mean small typos, > > spelling/grammar/punctuation/capitalization issues in docs, formatting, > > String literal alignment/wrapping issues, perhaps even missing @Overrides > > annotations, extra semicolons, unneeded warnings suppressions, etc. > > Essentially, things that are typically one-off changes that don't change > > the behavior or substance of the code or documentation, or that are > > self-contained, easily-understood, can be reasonably expected to be > > non-controversial, and which couldn't be further elaborated upon with a > > description in JIRA. Such changes would not include trivial bug fixes or > > feature enhancements, and are more likely to be described as style or > typo > > fixes. > > >
