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 15:22:40 GMT
With proper documentation, nothing, I agree with you. I suppose this is 
your real question, less so the practical application of how you ran 
into it.

Without trying to sound too much like a "that's just how it is", I think 
it would be confusing to suddenly not have some changes in the codebase 
represented anywhere in JIRA. While there's likely little value in 
seeing some hypothetical #2 JIRA issue in a fixVersion, at least I know 
that the *actual* changes contained in fixVersion are accurate. I've 
relied on this before.

If JIRA doesn't line up with the codebase, it has the potential to be a 
shocking change. Proper handling of what is "trivial" would likely not 
be a concern, but this kind of goes back to my original feeling that 
creating a JIRA issue is not so much work to bifurcate our workflow and 
create potential edge cases.

Christopher wrote:
> 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<josh.elser@gmail.com>  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.
>>>
>

Mime
View raw message