accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <josh.el...@gmail.com>
Subject Re: [DISCUSS] Trivial changes and git
Date Thu, 07 Jan 2016 14:54:29 GMT
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.
>

Mime
View raw message