accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [DISCUSS] Trivial changes and git
Date Thu, 07 Jan 2016 16:08:25 GMT
Creating Jira for trivial changes can be annoying.  To ease option 3 could
create a script that does the following.

 * does sanity check to ensure that commit is not pushed (not sure if this
can be better than a heuristic thats sometimes wrong)
 * creates Jira issue using commit message (and use paragraph after commit
message as description)
 * Sets fix version using snapshot version in pom
 * ammends commit message with issue number
 * opens a browser to the jira (if possible, would not in headless env)

On Wed, Jan 6, 2016 at 3:28 PM, Christopher <ctubbsii@apache.org> 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.
>

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