Re: Deriving release notes from git commit messages

From: Christopher Browne <cbbrowne(at)gmail(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Deriving release notes from git commit messages
Date: 2011-06-24 19:28:40
Message-ID: BANLkTim7LHTN5nUcN_Bx-GmYAgFTgJ49hA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 24, 2011 at 6:47 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> On 06/24/2011 01:42 PM, Robert Haas wrote:
>> I am not inclined to try to track sponsors in the commit message at
>> all.
>
> I was not suggesting that information be part of the commit.  We've worked
> out a reasonable initial process for the people working on sponsored
> features to record that information completely outside of the commit or
> release notes data.  It turns out though that process would be easier to
> drive if it were easier to derive a feature->{commit,author} list
> though--and that would spit out for free with the rest of this.  Improving
> the ability to do sponsor tracking is more of a helpful side-effect of
> something that's useful for other reasons rather than a direct goal.

In taking a peek at the documentation and comments out on the interweb
about "git amend," I don't think that it's going to be particularly
successful if we try to capture all this stuff in the commit message
and metadata, because it's tough to guarantee that *all* this data
would be correctly captured at commit time, and you can't revise it
after the commit gets pushed upstream.

That applies to anything we might want to track, whether "Author:" (at
the 'likely to be useful', and 'could quite readily get it correct the
first time' end of the spectrum) or "Sponsor:" (which is at more than
one dubious ends of spectra).

I expect that the correlation between commit and [various parties] is
something that will need to take place outside git.

The existing CommitFest data goes quite a long ways towards capturing
interesting information (with the likely exception of sponsorship);
what it's missing, at this point, is a capture of what commit or
commits wound up drawing the proposed patch into the official code
base. That suggests a pretty natural extension, and this is something
I really would like to see. I'd love to head to the CommitFest page,
and have a list of URLs pointing to the commits that implemented a
particular change.

Given that particular correspondence (e.g. - commitfest request ->
list of commits), that would help associate authors, reviewers, and
such to each commit that was related to CommitFest work. That doesn't
cover everything, but it's a plenty good start.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message karavelov 2011-06-24 19:31:29 FWD: fastlock+lazyvzid patch performance
Previous Message Robert Haas 2011-06-24 19:22:15 Re: Optimizing pg_trgm makesign() (was Re: WIP: Fast GiST index build)