accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Trivial changes and git
Date Thu, 07 Jan 2016 15:08:14 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message