[postgis-devel] PostGIS 3.4.0 beta2 in a couple of days?

[Regina Obe]

> On 7/28/23 19:47, Regina Obe wrote:
> >>> We've still got a couple more issues, like this i386 gcc13
> >>> regression which effects both PostGIS 3.3 and PostGIS 3.4
> >>> https://trac.osgeo.org/postgis/ticket/5448
> >>
> >> Alternatively, you can decide no longer support i386 as it's not part
> >> of CI for example.
> >
> > Our cis still test on i386 machines, but admittedly it seems most
> > people are running 64-bit these days.
> > You know what portion of people still run on i386 architectures?
> 
> Numbers are hard to come by, of the systems submitting popcon [0] reports
> for the release architectures in Debian are:
> 
>   207071 amd64
>     9709 i386
>     1393 arm64
>      677 armhf
>      259 armel
>       80 ppc64el
>       25 riscv64
>       12 s390x
>       12 mipsel
>        9 mips64el
> 
> Popcon is opt-in, so the actual number of systems is much larger. I do
think it
> reasonably reflects the relative popularity.
> 
> [0] https://popcon.debian.org/ (has a nice graph of the numbers)
> 
> > Even the raspberry pis which were the largest of the i386 I was seeing
> > are all switching to 64-bit.
> 
> Rasberry Pi is armel/armhf for the Pi 1/2, the Pi 3 and later are arm64.
> 
> > I don't bother testing or shipping for windows 32-bit anymore since no
> > EDB PostgreSQL installers offered anymore for 64-bit.
> Actual users of PostGIS on i386 are unlikely, just as they are on the
obscure
> architectures like mipsel and ppc64el. amd64 and arm64 are what people are
> most likely to use.
> 
> The discussion around the year-2038 issue [1] showed this sentiment to be
> quite popular:
> 
> "
>   i386 primarily exists for running legacy binaries and binary
>   compatibility with legacy executables is more important than correct
>   representation of time beyond 2038.
> "
> 
> PostGIS is not a legacy binary. Supporting i386 is not a high priority.
> Handling architecture quirks correctly makes for good technical
correctness,
> but is not the most efficient use of scarce contributor time.
> 
> [1] https://lwn.net/Articles/938149/
> 
> Kind Regards,
> 
> Bas
> 
> --
>   GPG Key ID: 4096R/6750F10AE88D4AF1
> Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

That's interesting. So it's higher than I thought.  I think it's still
worthwhile to keep maintaining them for a bit longer.
Especially since they have uncovered in the past issues with our code that
could show up in 64-bit but would take longer to show.

But we won't hold up releases for difficult issues because of i386 failures.
The good news is at least it does seem isolated to the gcc13 i386 as far as
I can see so we have a bit more time to work this out and at least it
compiles and most tests still pass.

Thanks,
Regina