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 Wed, 06 Jan 2016 21:05:52 GMT
To be clear, I'm not proposing we do any of #1, #2, or #3... those were
just observations of what people seem to be currently doing to get around
the psychological barrier of creating a separate JIRA.

In my original email, I listed some cons with each #1, #2, and #3. I don't
like any of them. #1 is problematic when the trivial change (which is
desirable to keep) gets carried with the other change, as though it were
part of it... through reverts/merges/reviews (especially reverts), etc. #2
and #3 seem to add no value to me, and have the disadvantage of distracting
the developer who must shift focus from their current task to go create
JIRA issues, etc., when a simple quick fix and commit would suffice. I'm
also opposed to the "leave it open" mentality, because these tickets tend
to be completely worthless... it takes time to find the right one to use,
and there are often multiple open for the same scope, and they offer
nothing that grepping the logs wouldn't give.

Rather than people find ways around the system, I think it's better if we
just admit that some commits are too trivial to track in JIRA (in addition
to git... where they are already tracked).

As for the role of git... I initially explained more why I thought that
mattered, but cut it out for brevity. I think git (or any similar VCS)
provides sufficient documentation if we ever actually did care when a
spelling mistake was fixed. I don't think JIRA adds any value here.... it's
just redundant. JIRA is for tracking future work, communicating progress on
identified problems and feature requests, and organizing/planning for
releases. None of these matter for "Fixed misspelling of 'teh' (the) in
javadoc". Git itself isn't significant, but the fact that we have a good
VCS means we don't really need to be that pedantic about requiring JIRA
references, IMO. So, I'd like to see us become less strict about it for
very trivial stuffs... in favor of encouraging more "commit often"
mentality with git to logically separate work.

I also mentioned git, because it is already the case that we have several
git commits which do not reference JIRA, because of the nature of git
specifically. In some cases, multiple commits were made on a branch,
without a reference, and then a reference was added at the HEAD commit
before merging (but could also have been added in the merge commit).
Because of the nature of git, we can easily see the reference at a
meaningful point in the commit graph, even for pull requests, even if each
commit doesn't have one. I've also noticed that, working with GitHub, it's
very nice that a pull-request is it's own issue. Similarly, I've come to
think that a commit hash is sufficient of an identifier to track trivial
commits when further elaboration isn't needed.

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