Re: Commitfest problems - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Commitfest problems
Date
Msg-id 5926.1419034613@sss.pgh.pa.us
Whole thread Raw
In response to Re: Commitfest problems  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Commitfest problems  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
> On 12/18/2014 05:36 PM, Stephen Frost wrote:
>>> I do agree that we need to give credit in some form, though.  I'm just
>>> saying can we please not put the responsibility on committers.

>> Ugh, yeah, I certainly wouldn't want to have to work out some complex
>> set of rules to be applied before each commit to define who can be
>> considered a "reviewer".  That said, most of the above list are
>> committers and those who aren't should be recognized in some fashion, so
>> I'm not sure that this is really a good example.

> This really doesn't sound that difficult. If the committers include all
> actual reviewers in the commit messages, then it will be fairly easy for
> someone else (me) to go through and pick out the relative handful of
> people who aren't already on the contributors list and check the level
> of their contributions.

I'm with Alvaro: I don't mind copying the commitfest app's credits list
into commit messages, but please don't ask me to review who should get
credit or not.  If I have to do it, it's going to be done hastily at the
tail end of the commit process, and probably not very well; and once the
commit is made it's not very practical to fix any mistakes.

Could we establish an expectation that whoever sets a CF entry to "ready
for committer" is responsible for reviewing the authors/reviewers lists
and making sure that those fairly represent who should get credit?  That
would divide the labor a bit, and there would also be time enough for
corrections if anyone feels slighted.  The idea's not perfect since major
contributions could still happen after that point; but I think the major
risk is with the committer not remembering people who contributed early
in the patch's life cycle, and we could certainly hope that such people
get listed in the CF app entry.

Alternatively we could abandon the practice of using the commit log for
this purpose, which could simplify making after-the-fact corrections.
But then we'd have to set up some other recording infrastructure and work
flow for getting the info into the release notes.  That sounds like a lot
of work compared to the probable value.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: hash_create API changes (was Re: speedup tidbitmap patch: hash BlockNumber)
Next
From: Peter Geoghegan
Date:
Subject: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}