I find creating JIRA issues to be a psychological barrier to making commits. Of course tickets are helpful for tracking changes to Accumulo, especially large ones. I would go for #1 with committer's discretion so that a committer could choose when a change is minor enough that it does not need a ticket. If a committer decides to go on a grand warning-hunt, then he or she could still open a "fix a bunch of warnings" commit for a collection of trivial changes, as opposed to random small trivial changes.
On Wed, Jan 6, 2016 at 3:48 PM, William Slacum <[email protected]> wrote: > I've worked on teams who had perpetually open tickets like "Solve warnings" > or "Fix typos". Those issues could be referenced in commits just say they > were involved with some changes. > > From your list, I think #1 is fine, and that #3 is preferable to #2. I > don't feel strongly to be honest, as the trivialness of the changes don't > pose a large QA risk either way. Do we realistically see the scenario of, > "I need to hunt down the commit where this spelling mistake was corrected > and it's hard to do because it's lumped in with a different patch set" > posing some great roadblock to us? > > Not to nitpick too much, but I think the significance of git in this > discussion is minimal-- the same problem could be had w/ any VCS. > > On Wed, Jan 6, 2016 at 3:28 PM, Christopher <[email protected]> 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. > > >
