Re: Commitfest 2023-03 starting tomorrow! - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Commitfest 2023-03 starting tomorrow!
Date
Msg-id CAM-w4HMUVZW3ECm18+wd56R530duQLepu2zLYxKt4ivE9iwUsA@mail.gmail.com
Whole thread Raw
In response to Re: Commitfest 2023-03 starting tomorrow!  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Commitfest 2023-03 starting tomorrow!
List pgsql-hackers
On Mon, 20 Mar 2023 at 16:08, Thomas Munro <thomas.munro@gmail.com> wrote:
>
> On Tue, Mar 21, 2023 at 3:15 AM Greg Stark <stark@mit.edu> wrote:
> > The next level of this would be something like notifying the committer
> > with a list of patches in the CF that a commit broke. I don't
> > immediately see how to integrate that with our workflow but I have
> > seen something like this work well in a previous job. When committing
> > code you often went and updated other unrelated projects to adapt to
> > the new API (or could adjust the code you were committing to cause
> > less breakage).
>
> I've been hesitant to make it send email.  The most obvious message to
> send would be "hello, you posted a patch, but it fails on CI" to the
> submitter.

Yeah, even aside from flappers there's the problem that it's about as
common for real commits to break some test as it is for patches to
start failing tests. So often it's a real failure but it's nothing to
do with the patch, it has to do with the commit that went into git.

What I'm interested in is something like "hey, your commit caused 17
patches to start failing tests". And it doesn't necessarily have to be
an email. Having a historical page so when I look at a patch I can go
check, "hey did this start failing at the same time as 17 other
patches on the same commit?" would be the same question.


--
greg



pgsql-hackers by date:

Previous
From: Corey Huinker
Date:
Subject: Re: Add SHELL_EXIT_CODE to psql
Next
From: Greg Stark
Date:
Subject: Re: Experiments with Postgres and SSL