accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject [DISCUSS] Trivial changes and git
Date Wed, 06 Jan 2016 20:28:11 GMT
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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message