accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dylan Hutchison <dhutc...@uw.edu>
Subject Re: [DISCUSS] Trivial changes and git
Date Wed, 06 Jan 2016 20:57:08 GMT
I find creating JIRA issues to be a psychological barrier to making
commits.  Of course tickets are helpful for tracking changes to Accumulo,
especially large ones.  I would go for #1 with committer's discretion so
that a committer could choose when a change is minor enough that it does
not need a ticket.  If a committer decides to go on a grand warning-hunt,
then he or she could still open a "fix a bunch of warnings" commit for a
collection of trivial changes, as opposed to random small trivial changes.

On Wed, Jan 6, 2016 at 3:48 PM, William Slacum <wslacum@gmail.com> wrote:

> I've worked on teams who had perpetually open tickets like "Solve warnings"
> or "Fix typos". Those issues could be referenced in commits just say they
> were involved with some changes.
>
> From your  list, I think #1 is fine, and that #3 is preferable to #2. I
> don't feel strongly to be honest, as the trivialness of the changes don't
> pose a large QA risk either way. Do we realistically see the scenario of,
> "I need to hunt down the commit where this spelling mistake was corrected
> and it's hard to do because it's lumped in with a different patch set"
> posing some great roadblock to us?
>
> Not to nitpick too much, but I think the significance of git in this
> discussion is minimal-- the same problem could be had w/ any VCS.
>
> 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