| From: | "Euler Taveira" <euler(at)eulerto(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Michael Paquier" <michael(at)paquier(dot)xyz> |
| Cc: | "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Andres Freund" <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Heads Up: cirrus-ci is shutting down June 1st |
| Date: | 2026-04-18 02:19:24 |
| Message-ID: | a8e80680-c4a6-4125-8500-ab31924f8d85@app.fastmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Apr 17, 2026, at 6:48 PM, Tom Lane wrote:
>
> I think running a test promptly after a new patch submission is
> useful, even for small patches. I agree that the periodic re-tests
> for bit-rot could be scaled back a lot.
>
That's my opinion too. This is particularly important for first-time
contributors that may not know about the Postgres development process. For
regular contributors, I expect that they have a CI setup and submit a new
version only after the patch passes CI in its own repository.
I'm not sure about restricting the CI runs to small patches. Although it is a
minority, there are small patches that has a big potential to break things.
Maybe an alternative to small and/or high-frequency patches is to not run them
automatically but have a mechanism to trigger them manually once detected. The
author or even one of the reviewers can trigger it.
--
Euler Taveira
EDB https://www.enterprisedb.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuya Kawata | 2026-04-18 03:29:19 | [PATCH] Doc: Fix missing func_signature role in pg_get_tablespace_ddl entry |
| Previous Message | William Bernbaum | 2026-04-17 23:29:05 | [PATCH] Fix pg_dump emitting OVERRIDING SYSTEM VALUE for tables with dropped identity columns |