From: | Wolfgang Walther <walther(at)technowledgy(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Building with musl in CI and the build farm |
Date: | 2024-04-04 15:01:32 |
Message-ID: | 12606570-50cc-4e66-9c5c-d9e61764551d@technowledgy.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Tom Lane:
> That is not the concern here. What I think Peter is worried about,
> and certainly what I'm worried about, is that a breakage in
> SanityCheck comprehensively breaks all CI testing for all Postgres
> developers.
You'd have to commit a failing patch first to break CI for all other
developers. If you're only going to commit patches that pass those CI
tasks, then this is not going to happen. Then it only becomes a question
of how much feedback *you* get from a single CI run of your own patch.
> To be blunt, I do not think we need to test musl in the CI pipeline.
> I see it as one of the niche platforms that the buildfarm exists
> to test.
I don't really have an opinion on this. I'm fine with having musl in the
buildfarm only. I don't expect the core build itself to fail with musl
anyway, this has been working fine for years. Andres asked for it to be
added to CI, so maybe he sees more value on top of just "building with
musl"?
Best,
Wolfgang
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-04-04 15:19:11 | Re: Building with musl in CI and the build farm |
Previous Message | Tom Lane | 2024-04-04 14:36:41 | Re: Building with musl in CI and the build farm |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-04-04 15:16:28 | Re: WIP Incremental JSON Parser |
Previous Message | Tom Lane | 2024-04-04 15:00:15 | Re: WIP Incremental JSON Parser |