Clarifying Commitfest policies

From: Jacob Champion <jchampion(at)timescale(dot)com>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Daniel Gustafsson <daniel(at)yesql(dot)se>
Subject: Clarifying Commitfest policies
Date: 2022-08-03 18:03:58
Message-ID: CAAWbhmiLV3P16OrGbywctkFUL5dc0p=zU1Ax83XZAK3BD9z=4Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

[was: CF app: add "Returned: Needs more interest"]

On Wed, Aug 3, 2022 at 10:09 AM Julien Rouhaud <rjuju123(at)gmail(dot)com> wrote:
> I'm afraid that
> patches will still be left alone to rot and there still be no clear rules on
> what to do and when, reminder for CFM and such, and that this new status would
> never be used anyway.

Yeah, so the lack of clear rules is an issue -- maybe not because we
can't work without them (we have, clearly, and we can continue to do
so) but because each of us kind of makes it up as we go along? When
discussions about these "rules" happen on the list, it doesn't always
happen with the same people, and opinions can vary wildly.

There have been a couple of suggestions recently:
- Revamp the CF Checklist on the wiki. I plan to do so later this
month, but that will still need some community review.
- Provide in-app explanations and documentation for some of the less
obvious points. (What should the target version be? What's the
difference between Rejected and Returned?)

Is that enough, or should we do more?

My preference, as I think Daniel also said in a recent thread, would
be for most of this information to be in the application somewhere.
That would make it more immediately accessible to everyone. (The
tradeoff is, it gets harder to update.)

--Jacob

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-08-03 18:06:58 Re: optimize lookups in snapshot [sub]xip arrays
Previous Message Alvaro Herrera 2022-08-03 18:01:48 Re: enable/disable broken for statement triggers on partitioned tables