On Thursday, May 29, 2025, Ashutosh Bapat <
ashutosh.bapat.oss@gmail.com> wrote:
On Fri, May 16, 2025 at 1:45 PM Jelte Fennema-Nio <
me@jeltef.nl> wrote:
On Fri, 16 May 2025 at 12:24, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
>
> On Fri, May 16, 2025 at 12:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > That outcome seems entirely horrible to me. If you want to flag the lack
> > of a commit message somehow, fine, but don't prevent CI from running.
>
> Personally I also prefer nudges to gates.
Okay, reasonable feedback. How about we add a CI job that does a
"quality check". That's much less strong, as all the other tests will
still run, but people would get a failing CI job which tells them that
something is wrong. We could also include a pgindent in that CI job.
+1. Knowing whether to use git am or patch to apply the patch itself will save reviewers' time.
Just tossing this out there: we have a nice shell script that applies patches in a directory to the checked out branch. Why not place that script into the postgres repo instead of having it in pgcommitfest?
That doesn’t preclude having the apply step of the process do more work/checks/feedback without impacting “tests passed or failed”. Does this need to run on CirrusCI (personal builds) or just within the commitfest app?
David J.
