From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Euler Taveira <euler(at)eulerto(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Opinion poll: Sending an automated email to a thread when it gets added to the commitfest |
Date: | 2024-09-26 15:05:52 |
Message-ID: | CA+TgmoZ2LvYPUHhjOv_oaMyvcj=hBeO70kf37d6PWd==iJ6ekg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 25, 2024 at 2:55 AM Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> wrote:
> Another thing that I'm interested in adding is some metric of patch
> size, so it's easier to find small patches that are thus hopefully
> "easy" to review. To accommodate multi-patch emails, I'm thinking of
> showing lines changed in the first patch and lines changed in all
> patches together. Possibly showing it clearly, if significantly more
> lines were deleted than added, so it's easy to spot effective
> refactorings.
I like this general idea. Anything that helps us figure out what to
pay attention to in the CommitFest is great stuff. Focusing on the
first patch seems odd to me, though: often the earlier patches will be
preparatory patches, so small, and the big patch is someplace near the
end of the series.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2024-09-26 15:41:18 | Re: pgsql: Implement pg_wal_replay_wait() stored procedure |
Previous Message | Tom Lane | 2024-09-26 15:04:33 | Re: Test improvements and minor code fixes for formatting.c. |