Re: Commitfest problems

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Commitfest problems
Дата
Msg-id 5926.1419034613@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Commitfest problems  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Commitfest problems  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: hash_create API changes (was Re: speedup tidbitmap patch: hash BlockNumber)
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}