On Wed, Dec 4, 2024 at 11:23 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> Wow, what a lot of variations we have to handle with no coverage. I'm
> coming around to your proposal Robert. We decide that it is OK to
> back-patch freely, under a policy along the lines "we try to keep
> stable branches working on the latest MinGW toolchain version only, as
> a developer convenience". Even if it creates contradictions in
> back-branches (using some stuff unguarded, even if other stuff is
> guarded because it needed to be at the time). I'm not sure what
> quorum is needed for such a decree, but from a verification point of
> view, that's the effective reality already. An interested party would
> need to show up with the resources to maintain another platform
> variant; so yeah, why not let them do that, if something we back-patch
> turns out to be a real problem for them?
I don't want to go too far in the direction of being willing to break
things in the back-branches, for obvious reasons. But in a case like
this, we definitely have a bug that is affecting users on Windows, and
we can't verify whether the fallback code is correct or would ever be
used by anyone. If you think that fallback code is reasonably likely
to be correct and work, I'm not against including it. But if we really
have no idea, then IMHO it's reasonable to ship something that we
expect to cause a hard failure on such platforms if they exist (like a
missing symbol). That way, if they do exist, we'll be more likely to
find about it and therefore more likely to be able to deliver a
complete and proper fix, vs. shipping something that might be quite
wrong and praying that it isn't.
--
Robert Haas
EDB: http://www.enterprisedb.com
