Re: Commitfest Update - Mailing list pgsql-hackers

On Fri, 8 Jul 2022, 23:41 Jacob Champion, <jchampion@timescale.com> wrote:
>
> On 3/31/22 07:37, Tom Lane wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> On Thu, Mar 31, 2022 at 10:11 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> ... Would it be feasible or reasonable
>>>> to drop reviewers if they've not commented in the thread in X amount
>>>> of time?
>>
>>> In theory, this might cause someone who made a valuable contribution
>>> to the discussion to not get credited in the commit message. But it
>>> probably wouldn't in practice, because I at least always construct the
>>> list of reviewers from the thread, not the CF app, since that tends to
>>> be wildly inaccurate in both directions. So maybe it's fine? Not sure.
>>
>> Hmm, I tend to believe what's in the CF app, so maybe I'm dropping the
>> ball on review credits :-(.  But there are various ways we could implement
>> this.  One way would be a nagbot that sends private email along the lines
>> of "you haven't commented on patch X in Y months.  Please remove your name
>> from the list of reviewers if you don't intend to review it any more."
>
> It seems there wasn't a definitive decision here. Are there any
> objections to more aggressive pruning of the Reviewers entries? So
> committers would need to go through the thread for full attribution,
> moving forward.
>
> If there are no objections, I'll start doing that during next Friday's
> patch sweep.


No objections, but this adds another item to the implicit commitfest
app user manual, that to the best of my knowledge seems to be mostly
implicit institutional knowledge plus bits of information spread
around the mailing lists.

Do we have an actual manual or otherwise a (single?) place with
documentation on how certain fields of the CFA should be used or
interpreted, so that (new) hackers know what to expect or where to
look?

Examples of information about using the CFA that I couldn't find:
- The Version field may contain a single specific postgresql version
number, 'stable', or nothing. If my patch needs backpatching to all
backbranches, which do I select? The oldest supported PG version, or
'stable'? Related to that: which version is indicated by 'stable'?

- When creating or updating a CF entry, who are responsible for
filling in which fields? May the author assign reviewers/committers,
or should they do so themselves?

- Should the 'git link' be filled with a link to the committed patch
once committed, or is it a general purpose link to share a git
repository with the proposed changes?

- What should (or shoudn't) Annotations be used for?

- What should I expect of the comment / review system of the CFA?
Should I use feature over direct on-list mails?

I have checked the wiki page on becoming a developer [0], but that
page seems woefully outdated with statements like "Commitfests are
scheduled to start on the 15th of the month" which hasn't been true
since 2015. The pages on Commitfests [1] and the Developer FAQ [2]
don't add much help either on how to use the CommitFest app. Even
(parts of) the checklist for the CFM on the wiki [3] still assumes the
old CF app that was last used in 2014: "It's based on the current
CommitFest app (written by Robert Haas), and will change once the new
CF App is done."

I'm not asking anyone to drop all and get all the features of the CFA
documented, but for my almost 2 years of following the -hackers list I
feel like I still haven't gotten a good understanding of the
application that is meant to coordinate the shared state in patch
development, and I think that's a quite a shame.

-Matthias

[0] https://wiki.postgresql.org/wiki/So,_you_want_to_be_a_developer%3F
[1] https://wiki.postgresql.org/wiki/CommitFest
[2] https://wiki.postgresql.org/wiki/Developer_FAQ
[3] https://wiki.postgresql.org/wiki/CommitFest_Checklist