hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Consider adding the issue number in commit message
Date Wed, 14 Sep 2016 17:05:01 GMT
On Tue, Sep 13, 2016 at 2:30 PM, Xi Yang <alex.xi.yang@gmail.com> wrote:

> +1
> If I don't put Jira issue number in commit message then I don't know
> whatelse I can put. Jira issue number already contain all the information
> of your commitment and it makes the commitment traceable .  So I suggest we
> don't need to say any other words except Jira issue number and the title.
>
> The whole commitment message should be "HBASE-<number> xxxxxxxxx"
>
> That will make our got history looks clear
>
>
You bring up an interesting item Xi Yang.

Commit messages that have just 'HBASE-XXXX <Subject>' are not enough IMO.
The patch for sure should start with this one-liner -- for all the reasons
given above -- but it should be followed by a succinct description of what
the patch does. Going to JIRAs that are often pages long w/ a back and
forth on how a fix should be done are a time-consuming parse and in the
end, may have little relation to what is actually committed. Better
all-around -- from forcing the contributor to gather their thoughts to make
a terse summary, to the downstreamer backporting trying to make an
assessment on whether a patch important or not -- that we do like any other
project of substance and take the time to do decent, descriptive commit
messages.

Let me update the refguide with our agreement here on no forced-pushes to
any branch. I thought it in the guide already but it is not.

On writing scripts to check the format of commits, we already have a very
fine one. See ./dev-support/submit-patch.py All should be using it, at
least all committers (contributors have the excuse that they don't know of
it). Not only does this script save the contributor time, because it does
git format-patch auto-adding the jira subject and id as well as
auto-posting review board, it makes the committers life easier too as they
can just git am the patch if all looks good (and it will includes, whole,
any commit message a dev might have written up too).

St.Ack



> Thanks
> Alex
>
> On Tuesday, 13 September 2016, Dima Spivak <dimaspivak@apache.org> wrote:
>
> > +1 to that, Enis.
> >
> > -Dima
> >
> > On Tue, Sep 13, 2016 at 2:15 PM, Enis Söztutar <enis@apache.org
> > <javascript:;>> wrote:
> >
> > > +1 on not force pushing. The git repo is sync'ed to multiple places
> (like
> > > github, etc) so force pushes should be avoided unless a feature branch.
> > >
> > > Should we extend the list of no-force-pushes to all active release
> > branches
> > > (branch-1, branch-1.2, branch-1.1, etc)?
> > >
> > > Enis
> > >
> > > On Tue, Sep 13, 2016 at 1:46 PM, Ted Yu <yuzhihong@gmail.com
> > <javascript:;>> wrote:
> > >
> > > > Interesting.
> > > >
> > > > I can try to write a script which:
> > > > given JIRA number (e.g. 16491), emits HBASE-xyz Description (author)
> > > >
> > > > The output can then be copy-pasted in commit.
> > > >
> > > > Cheers
> > > >
> > > > On Tue, Sep 13, 2016 at 12:57 PM, Jerry He <jerryjch@gmail.com
> > <javascript:;>> wrote:
> > > >
> > > > > I have made similar mistakes on the commit messages previously,
> (and
> > > > people
> > > > > here on this thread had kindly reminded me on the JIRA before).
> > > > > I was wondering if some automatic enforcement could be set up, on
> the
> > > > > server side, or on the client side.
> > > > >
> > > > > On Tue, Sep 13, 2016 at 11:18 AM, Andrew Purtell <
> > apurtell@apache.org <javascript:;>>
> > > > > wrote:
> > > > >
> > > > > > Big +1
> > > > > >
> > > > > > JIRA identifiers in commit issues must be mandatory.
> > > > > >
> > > > > > Occasionally a committer makes a mistake. We're human. Simply
> > revert
> > > > and
> > > > > > push up a fixed commit.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Sep 13, 2016 at 10:16 AM, Sean Busbey <
> busbey@cloudera.com
> > <javascript:;>>
> > > > > wrote:
> > > > > >
> > > > > > > On Tue, Sep 13, 2016 at 10:00 AM, Gary Helmling <
> > > ghelmling@gmail.com <javascript:;>
> > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > >> To fix erroneous commit messages, please revert
the
> offending
> > > > > commits
> > > > > > > >> and then reapply them with a correct commit message.
> > > > > > > >>
> > > > > > > >>
> > > > > > > > Honestly, I don't see the point of this.  In this
case the
> > > original
> > > > > > > commit
> > > > > > > > is still there, so nothing is really fixed.  Instead
we wind
> up
> > > > with
> > > > > 3
> > > > > > > > commits muddying up the change history for the affected
> files.
> > > > > > > >
> > > > > > > > I would much rather preserve a clean change history
at the
> cost
> > > of
> > > > a
> > > > > > few
> > > > > > > > bad commit messages.  I don't think it's really that
big a
> > deal.
> > > > > > >
> > > > > > > We rely on the commit messages in git for both authorship
and
> as
> > a
> > > > > > > sanity check against the information in JIRA. It may not
seem
> > like
> > > a
> > > > > > > big deal in the small when one of these is missing, but
it adds
> > up
> > > to
> > > > > > > making more work for folks who are trying to do necessary
and
> > > already
> > > > > > > unpopular tasks.
> > > > > > >
> > > > > > > The authorship information is mostly a nice-to-have for
> checking
> > on
> > > > > > > activity levels in the project. As a PMC member that
> information
> > is
> > > > > > > important to me. I can get it from JIRA as well, but that's
> more
> > > > work.
> > > > > > >
> > > > > > > The JIRA key in the commit message is a key part of how
we do
> > > sanity
> > > > > > > checks on the information in JIRA come release time. Please
> make
> > > sure
> > > > > > > you correct erroneous commits that miss it or use the wrong
> JIRA
> > > key.
> > > > > > > Otherwise you put a bunch more work on folks doing RM duty
(or
> > > > atleast
> > > > > > > me when I do RM duty), because we have to do a lot more
to
> track
> > > down
> > > > > > > what's going on when JIRA says an issue is fixed but git
> doesn't
> > > > agree
> > > > > > > (or vice versa).
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > busbey
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > >
> > > > > >    - Andy
> > > > > >
> > > > > > Problems worthy of attack prove their worth by hitting back.
-
> Piet
> > > > Hein
> > > > > > (via Tom White)
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message