From lr at pcorp.us  Mon Jun  1 13:25:44 2026
From: lr at pcorp.us (Regina Obe)
Date: Mon, 1 Jun 2026 16:25:44 -0400
Subject: PSC Vote: PostGIS 3.7.0 beta1
Message-ID: <000401dcf204$d34a38c0$79deaa40$@pcorp.us>

I'd like to release a PostGIS 3.7.0 beta 1 soon say in about a week.
PostgreSQL 19 beta1 is due out any moment.  So would be good to have people
start testing PostGIS 3.7.0 beta1 along side it.

Are there any additional SQL API facing changes people are planning for that
they haven't committed?

Anyway +1 from me for release.

Thanks,
Regina


From pramsey at cleverelephant.ca  Mon Jun  1 13:26:50 2026
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Mon, 1 Jun 2026 13:26:50 -0700
Subject: PSC Vote: PostGIS 3.7.0 beta1
In-Reply-To: <000401dcf204$d34a38c0$79deaa40$@pcorp.us>
References: <000401dcf204$d34a38c0$79deaa40$@pcorp.us>
Message-ID: <CACowWR3Xg287bHPqBSFHsLTQNTZ0UX_A0Jz=btq4M4Tsfb_z=w@mail.gmail.com>

+1 from me too

On Mon, Jun 1, 2026 at 1:25?PM Regina Obe <lr at pcorp.us> wrote:
>
> I'd like to release a PostGIS 3.7.0 beta 1 soon say in about a week.
> PostgreSQL 19 beta1 is due out any moment.  So would be good to have people
> start testing PostGIS 3.7.0 beta1 along side it.
>
> Are there any additional SQL API facing changes people are planning for that
> they haven't committed?
>
> Anyway +1 from me for release.
>
> Thanks,
> Regina
>

From pramsey at cleverelephant.ca  Fri Jun  5 14:06:52 2026
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Fri, 5 Jun 2026 14:06:52 -0700
Subject: address_standardizer/tiger_geocoder split
Message-ID: <CACowWR2=uO99xq9bofC9gbGcRzqHwsm5ivyEyrTVHXkpuvEkVg@mail.gmail.com>

Hey developers, a little update you might not have noticed but that
has important implications for packagers.

>From NEWS:

- #6053, [address_standardizer] Extension removed and moved to
  https://github.com/postgis/address_standardizer (Paul Ramsey)
- #6052, [tiger_geocoder] Extension removed and moved to
  https://git.osgeo.org/postgis/postgis_tiger_geocoder (Regina Obe)

They have been split off of the main repo because they are
structurally independent. In the case of address_standardizer, also
basically developmentally dormant. In the case of the geocoder,
governed by a different release cadence (the US Census data release
cadence) than the rest of the PostGIS suite, which dances to the PgSQL
cadence.

ATB,
P

From pramsey at cleverelephant.ca  Fri Jun  5 16:49:29 2026
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Fri, 5 Jun 2026 16:49:29 -0700
Subject: 3.6.4 Release
Message-ID: <74FFEE50-9577-4B87-ACC2-6396ED39C8FB@cleverelephant.ca>

While we do not have a lot of changes since the last release, we do have an important fix to upgrading which resolves (mitigates) a long-time issue with SRID lookup during upgrade, as well as a security patch which I would like to put to bed.  Since there will be a lot of PostGIS packages cut over the summer I would like those packages to have these changes.

+1 (numbers are cheap)

P

From gdt at lexort.com  Sat Jun  6 10:58:34 2026
From: gdt at lexort.com (Greg Troxel)
Date: Sat, 06 Jun 2026 13:58:34 -0400
Subject: 3.6.4 Release
In-Reply-To: <74FFEE50-9577-4B87-ACC2-6396ED39C8FB@cleverelephant.ca> (Paul
 Ramsey's message of "Fri, 5 Jun 2026 16:49:29 -0700")
References: <74FFEE50-9577-4B87-ACC2-6396ED39C8FB@cleverelephant.ca>
Message-ID: <rmi4ijfv9dh.fsf@s1.lexort.com>

I'm trying to build from git stable-3.6 to test pre-release.  I'm pretty
sure I've done this, but I don't have a clear memory.

I ran ./autogen.sh, and then ./configure --prefix=/usr/pkg.

versions of installed things that might matter

  -rw-r--r--  1 root  wheel    48608 Oct 27  2025 geos-3.14.1
  -rw-r--r--  1 root  wheel   118831 May 15 15:10 postgresql16-client-16.14
  -rw-r--r--  1 root  wheel   111907 May 15 15:28 postgresql16-server-16.14
  -rw-r--r--  1 root  wheel    31687 May 15 15:33 postgresql16-contrib-16.14
  -rw-r--r--  1 root  wheel    28821 May 31 08:05 protobuf-35.0
  -rw-r--r--  1 root  wheel    22330 May 31 08:07 py313-protobuf-7.35.0
  -rw-r--r--  1 root  wheel     1225 May 31 20:28 protobuf-c-1.5.2nb3
  -rw-r--r--  1 root  wheel    97900 Jun  1 20:30 postgresql16-postgis-3.6.3nb1
  -rw-r--r--  1 root  wheel     2001 Jun  4 15:04 uthash-2.3.0


I ran gmake -j8, and reran what failed.  It looks like a clash over who
gets to define HASH_ stuff.   Any clues?

I was going to 'make dist', but that didn't work and the HOWTO_RELEASE
says to invoke a remote opaque oracle :-) that I lack permission to
access.   So I'm unclear on what would be in a 3.6.4 if there was one -
I would try that in pkgsrc.  Maybe it's just git and autogen?







/usr/pkg/bin/perl ./utils/repo_revision.pl
Not updating existing rev file at 3.6.3-11-gbc9704020
for s in liblwgeom deps libpgcommon postgis regress topology  doc raster loader utils extensions; do \
	echo "---- Making all in ${s}"; \
	gmake -C ${s} all || exit 1; \
done;
---- Making all in liblwgeom
gmake[1]: Entering directory '/n0/gdt/SOFTWARE/GEO/POSTGIS/postgis/liblwgeom'
gmake[1]: Nothing to be done for 'all'.
gmake[1]: Leaving directory '/n0/gdt/SOFTWARE/GEO/POSTGIS/postgis/liblwgeom'
---- Making all in deps
gmake[1]: Entering directory '/n0/gdt/SOFTWARE/GEO/POSTGIS/postgis/deps'
gmake -C wagyu libwagyu.la
gmake[2]: Entering directory '/n0/gdt/SOFTWARE/GEO/POSTGIS/postgis/deps/wagyu'
gmake[2]: 'libwagyu.la' is up to date.
gmake[2]: Leaving directory '/n0/gdt/SOFTWARE/GEO/POSTGIS/postgis/deps/wagyu'
gmake -C ryu libryu.la
gmake[2]: Entering directory '/n0/gdt/SOFTWARE/GEO/POSTGIS/postgis/deps/ryu'
gmake[2]: 'libryu.la' is up to date.
gmake[2]: Leaving directory '/n0/gdt/SOFTWARE/GEO/POSTGIS/postgis/deps/ryu'
gmake -C flatgeobuf libflatgeobuf.la
gmake[2]: Entering directory '/n0/gdt/SOFTWARE/GEO/POSTGIS/postgis/deps/flatgeobuf'
gmake[2]: 'libflatgeobuf.la' is up to date.
gmake[2]: Leaving directory '/n0/gdt/SOFTWARE/GEO/POSTGIS/postgis/deps/flatgeobuf'
gmake[1]: Leaving directory '/n0/gdt/SOFTWARE/GEO/POSTGIS/postgis/deps'
---- Making all in libpgcommon
gmake[1]: Entering directory '/n0/gdt/SOFTWARE/GEO/POSTGIS/postgis/libpgcommon'
gmake[1]: Nothing to be done for 'all'.
gmake[1]: Leaving directory '/n0/gdt/SOFTWARE/GEO/POSTGIS/postgis/libpgcommon'
---- Making all in postgis
gmake[1]: Entering directory '/n0/gdt/SOFTWARE/GEO/POSTGIS/postgis/postgis'
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -O2 -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2 -I/usr/include/readline -I/usr/pkg/include -fPIC -DPIC -fvisibility=hidden -I../liblwgeom -I../liblwgeom -std=gnu11 -g -O2 -fno-math-errno -fno-signed-zeros -Wall -O2 -I../libpgcommon -I../deps/flatgeobuf -I../deps/wagyu -I../deps/uthash/include  -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include/libxml2  -I/usr/pkg/include -I/usr/pkg/include/json-c -I/usr/pkg/include -DNDEBUG   -fPIC -DPIC -I. -I./ -I/usr/pkg/include/postgresql/server -I/usr/pkg/include/postgresql/internal -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2 -I/usr/include/readline -I/usr/pkg/include  -I/usr/pkg/include/libxml2 -I/usr/pkg/include -I/usr/pkg/include  -c -o mvt.o mvt.c
In file included from /usr/pkg/include/postgresql/server/storage/shmem.h:24,
                 from /usr/pkg/include/postgresql/server/storage/lock.h:25,
                 from /usr/pkg/include/postgresql/server/catalog/namespace.h:18,
                 from mvt.h:35,
                 from mvt.c:30:
mvt.c: In function ?get_key_index_with_size?:
/usr/pkg/include/postgresql/server/utils/hsearch.h:98:23: error: called object is not a function or function pointer
   98 | #define HASH_FUNCTION 0x0040 /* Set user defined hash function */
      |                       ^~~~~~
/usr/pkg/include/uthash.h:151:3: note: in expansion of macro ?HASH_FUNCTION?
  151 |   HASH_FUNCTION(keyptr, keylen, hashv);                                          \
      |   ^~~~~~~~~~~~~
/usr/pkg/include/uthash.h:171:5: note: in expansion of macro ?HASH_VALUE?
  171 |     HASH_VALUE(keyptr, keylen, _hf_hashv);                                       \
      |     ^~~~~~~~~~
mvt.c:319:2: note: in expansion of macro ?HASH_FIND?
  319 |  HASH_FIND(hh, ctx->keys_hash, name, size, kv);
      |  ^~~~~~~~~
mvt.c: In function ?add_key?:
/usr/pkg/include/postgresql/server/utils/hsearch.h:98:23: error: called object is not a function or function pointer
   98 | #define HASH_FUNCTION 0x0040 /* Set user defined hash function */
      |                       ^~~~~~
/usr/pkg/include/uthash.h:151:3: note: in expansion of macro ?HASH_FUNCTION?
  151 |   HASH_FUNCTION(keyptr, keylen, hashv);                                          \
      |   ^~~~~~~~~~~~~
/usr/pkg/include/uthash.h:421:3: note: in expansion of macro ?HASH_VALUE?
  421 |   HASH_VALUE(keyptr, keylen_in, _ha_hashv);                                      \
      |   ^~~~~~~~~~
mvt.c:332:2: note: in expansion of macro ?HASH_ADD_KEYPTR?
  332 |  HASH_ADD_KEYPTR(hh, ctx->keys_hash, name, size, kv);
      |  ^~~~~~~~~~~~~~~
mvt.c: In function ?add_value_as_string_with_size?:
/usr/pkg/include/postgresql/server/utils/hsearch.h:98:23: error: called object is not a function or function pointer
   98 | #define HASH_FUNCTION 0x0040 /* Set user defined hash function */
      |                       ^~~~~~
/usr/pkg/include/uthash.h:151:3: note: in expansion of macro ?HASH_FUNCTION?
  151 |   HASH_FUNCTION(keyptr, keylen, hashv);                                          \
      |   ^~~~~~~~~~~~~
mvt.c:512:2: note: in expansion of macro ?HASH_VALUE?
  512 |  HASH_VALUE(value, size, hashv);
      |  ^~~~~~~~~~
mvt.c: In function ?parse_jsonb?:
/usr/pkg/include/postgresql/server/utils/hsearch.h:98:23: error: called object is not a function or function pointer
   98 | #define HASH_FUNCTION 0x0040 /* Set user defined hash function */
      |                       ^~~~~~
/usr/pkg/include/uthash.h:151:3: note: in expansion of macro ?HASH_FUNCTION?
  151 |   HASH_FUNCTION(keyptr, keylen, hashv);                                          \
      |   ^~~~~~~~~~~~~
mvt.c:455:4: note: in expansion of macro ?HASH_VALUE?
  455 |    HASH_VALUE(&newvalue, size, hashv); \
      |    ^~~~~~~~~~
mvt.c:596:5: note: in expansion of macro ?MVT_PARSE_VALUE?
  596 |     MVT_PARSE_VALUE(bool_values_hash,
      |     ^~~~~~~~~~~~~~~
/usr/pkg/include/postgresql/server/utils/hsearch.h:98:23: error: called object is not a function or function pointer
   98 | #define HASH_FUNCTION 0x0040 /* Set user defined hash function */
      |                       ^~~~~~
/usr/pkg/include/uthash.h:151:3: note: in expansion of macro ?HASH_FUNCTION?
  151 |   HASH_FUNCTION(keyptr, keylen, hashv);                                          \
      |   ^~~~~~~~~~~~~
mvt.c:455:4: note: in expansion of macro ?HASH_VALUE?
  455 |    HASH_VALUE(&newvalue, size, hashv); \
      |    ^~~~~~~~~~
mvt.c:614:6: note: in expansion of macro ?MVT_PARSE_VALUE?
  614 |      MVT_PARSE_VALUE(double_values_hash,
      |      ^~~~~~~~~~~~~~~
/usr/pkg/include/postgresql/server/utils/hsearch.h:98:23: error: called object is not a function or function pointer
   98 | #define HASH_FUNCTION 0x0040 /* Set user defined hash function */
      |                       ^~~~~~
/usr/pkg/include/uthash.h:151:3: note: in expansion of macro ?HASH_FUNCTION?
  151 |   HASH_FUNCTION(keyptr, keylen, hashv);                                          \
      |   ^~~~~~~~~~~~~
mvt.c:455:4: note: in expansion of macro ?HASH_VALUE?
  455 |    HASH_VALUE(&newvalue, size, hashv); \
      |    ^~~~~~~~~~
mvt.c:477:4: note: in expansion of macro ?MVT_PARSE_VALUE?
  477 |    MVT_PARSE_VALUE(uint_values_hash, \
      |    ^~~~~~~~~~~~~~~
mvt.c:622:6: note: in expansion of macro ?MVT_PARSE_INT_VALUE?
  622 |      MVT_PARSE_INT_VALUE(l);
      |      ^~~~~~~~~~~~~~~~~~~
/usr/pkg/include/postgresql/server/utils/hsearch.h:98:23: error: called object is not a function or function pointer
   98 | #define HASH_FUNCTION 0x0040 /* Set user defined hash function */
      |                       ^~~~~~
/usr/pkg/include/uthash.h:151:3: note: in expansion of macro ?HASH_FUNCTION?
  151 |   HASH_FUNCTION(keyptr, keylen, hashv);                                          \
      |   ^~~~~~~~~~~~~
mvt.c:455:4: note: in expansion of macro ?HASH_VALUE?
  455 |    HASH_VALUE(&newvalue, size, hashv); \
      |    ^~~~~~~~~~
mvt.c:486:4: note: in expansion of macro ?MVT_PARSE_VALUE?
  486 |    MVT_PARSE_VALUE(sint_values_hash, \
      |    ^~~~~~~~~~~~~~~
mvt.c:622:6: note: in expansion of macro ?MVT_PARSE_INT_VALUE?
  622 |      MVT_PARSE_INT_VALUE(l);
      |      ^~~~~~~~~~~~~~~~~~~
mvt.c: In function ?parse_values?:
/usr/pkg/include/postgresql/server/utils/hsearch.h:98:23: error: called object is not a function or function pointer
   98 | #define HASH_FUNCTION 0x0040 /* Set user defined hash function */
      |                       ^~~~~~
/usr/pkg/include/uthash.h:151:3: note: in expansion of macro ?HASH_FUNCTION?
  151 |   HASH_FUNCTION(keyptr, keylen, hashv);                                          \
      |   ^~~~~~~~~~~~~
mvt.c:455:4: note: in expansion of macro ?HASH_VALUE?
  455 |    HASH_VALUE(&newvalue, size, hashv); \
      |    ^~~~~~~~~~
mvt.c:497:3: note: in expansion of macro ?MVT_PARSE_VALUE?
  497 |   MVT_PARSE_VALUE(hash, value, size, pfvaluefield, pftype); \
      |   ^~~~~~~~~~~~~~~
mvt.c:726:4: note: in expansion of macro ?MVT_PARSE_DATUM?
  726 |    MVT_PARSE_DATUM(protobuf_c_boolean,
      |    ^~~~~~~~~~~~~~~
/usr/pkg/include/postgresql/server/utils/hsearch.h:98:23: error: called object is not a function or function pointer
   98 | #define HASH_FUNCTION 0x0040 /* Set user defined hash function */
      |                       ^~~~~~
/usr/pkg/include/uthash.h:151:3: note: in expansion of macro ?HASH_FUNCTION?
  151 |   HASH_FUNCTION(keyptr, keylen, hashv);                                          \
      |   ^~~~~~~~~~~~~
mvt.c:455:4: note: in expansion of macro ?HASH_VALUE?
  455 |    HASH_VALUE(&newvalue, size, hashv); \
      |    ^~~~~~~~~~
mvt.c:477:4: note: in expansion of macro ?MVT_PARSE_VALUE?
  477 |    MVT_PARSE_VALUE(uint_values_hash, \
      |    ^~~~~~~~~~~~~~~
mvt.c:503:2: note: in expansion of macro ?MVT_PARSE_INT_VALUE?
  503 |  MVT_PARSE_INT_VALUE(value); \
      |  ^~~~~~~~~~~~~~~~~~~
mvt.c:734:4: note: in expansion of macro ?MVT_PARSE_INT_DATUM?
  734 |    MVT_PARSE_INT_DATUM(int16_t, DatumGetInt16);
      |    ^~~~~~~~~~~~~~~~~~~
/usr/pkg/include/postgresql/server/utils/hsearch.h:98:23: error: called object is not a function or function pointer
   98 | #define HASH_FUNCTION 0x0040 /* Set user defined hash function */
      |                       ^~~~~~
/usr/pkg/include/uthash.h:151:3: note: in expansion of macro ?HASH_FUNCTION?
  151 |   HASH_FUNCTION(keyptr, keylen, hashv);                                          \
      |   ^~~~~~~~~~~~~
mvt.c:455:4: note: in expansion of macro ?HASH_VALUE?
  455 |    HASH_VALUE(&newvalue, size, hashv); \
      |    ^~~~~~~~~~
mvt.c:486:4: note: in expansion of macro ?MVT_PARSE_VALUE?
  486 |    MVT_PARSE_VALUE(sint_values_hash, \
      |    ^~~~~~~~~~~~~~~
mvt.c:503:2: note: in expansion of macro ?MVT_PARSE_INT_VALUE?
  503 |  MVT_PARSE_INT_VALUE(value); \
      |  ^~~~~~~~~~~~~~~~~~~
mvt.c:734:4: note: in expansion of macro ?MVT_PARSE_INT_DATUM?
  734 |    MVT_PARSE_INT_DATUM(int16_t, DatumGetInt16);
      |    ^~~~~~~~~~~~~~~~~~~
/usr/pkg/include/postgresql/server/utils/hsearch.h:98:23: error: called object is not a function or function pointer
   98 | #define HASH_FUNCTION 0x0040 /* Set user defined hash function */
      |                       ^~~~~~
/usr/pkg/include/uthash.h:151:3: note: in expansion of macro ?HASH_FUNCTION?
  151 |   HASH_FUNCTION(keyptr, keylen, hashv);                                          \
      |   ^~~~~~~~~~~~~
mvt.c:455:4: note: in expansion of macro ?HASH_VALUE?
  455 |    HASH_VALUE(&newvalue, size, hashv); \
      |    ^~~~~~~~~~
mvt.c:477:4: note: in expansion of macro ?MVT_PARSE_VALUE?
  477 |    MVT_PARSE_VALUE(uint_values_hash, \
      |    ^~~~~~~~~~~~~~~
mvt.c:503:2: note: in expansion of macro ?MVT_PARSE_INT_VALUE?
  503 |  MVT_PARSE_INT_VALUE(value); \
      |  ^~~~~~~~~~~~~~~~~~~
mvt.c:737:4: note: in expansion of macro ?MVT_PARSE_INT_DATUM?
  737 |    MVT_PARSE_INT_DATUM(int32_t, DatumGetInt32);
      |    ^~~~~~~~~~~~~~~~~~~
/usr/pkg/include/postgresql/server/utils/hsearch.h:98:23: error: called object is not a function or function pointer
   98 | #define HASH_FUNCTION 0x0040 /* Set user defined hash function */
      |                       ^~~~~~
/usr/pkg/include/uthash.h:151:3: note: in expansion of macro ?HASH_FUNCTION?
  151 |   HASH_FUNCTION(keyptr, keylen, hashv);                                          \
      |   ^~~~~~~~~~~~~
mvt.c:455:4: note: in expansion of macro ?HASH_VALUE?
  455 |    HASH_VALUE(&newvalue, size, hashv); \
      |    ^~~~~~~~~~
mvt.c:486:4: note: in expansion of macro ?MVT_PARSE_VALUE?
  486 |    MVT_PARSE_VALUE(sint_values_hash, \
      |    ^~~~~~~~~~~~~~~
mvt.c:503:2: note: in expansion of macro ?MVT_PARSE_INT_VALUE?
  503 |  MVT_PARSE_INT_VALUE(value); \
      |  ^~~~~~~~~~~~~~~~~~~
mvt.c:737:4: note: in expansion of macro ?MVT_PARSE_INT_DATUM?
  737 |    MVT_PARSE_INT_DATUM(int32_t, DatumGetInt32);
      |    ^~~~~~~~~~~~~~~~~~~
/usr/pkg/include/postgresql/server/utils/hsearch.h:98:23: error: called object is not a function or function pointer
   98 | #define HASH_FUNCTION 0x0040 /* Set user defined hash function */
      |                       ^~~~~~
/usr/pkg/include/uthash.h:151:3: note: in expansion of macro ?HASH_FUNCTION?
  151 |   HASH_FUNCTION(keyptr, keylen, hashv);                                          \
      |   ^~~~~~~~~~~~~
mvt.c:455:4: note: in expansion of macro ?HASH_VALUE?
  455 |    HASH_VALUE(&newvalue, size, hashv); \
      |    ^~~~~~~~~~
mvt.c:477:4: note: in expansion of macro ?MVT_PARSE_VALUE?
  477 |    MVT_PARSE_VALUE(uint_values_hash, \
      |    ^~~~~~~~~~~~~~~
mvt.c:503:2: note: in expansion of macro ?MVT_PARSE_INT_VALUE?
  503 |  MVT_PARSE_INT_VALUE(value); \
      |  ^~~~~~~~~~~~~~~~~~~
mvt.c:740:4: note: in expansion of macro ?MVT_PARSE_INT_DATUM?
  740 |    MVT_PARSE_INT_DATUM(int64_t, DatumGetInt64);
      |    ^~~~~~~~~~~~~~~~~~~
/usr/pkg/include/postgresql/server/utils/hsearch.h:98:23: error: called object is not a function or function pointer
   98 | #define HASH_FUNCTION 0x0040 /* Set user defined hash function */
      |                       ^~~~~~
/usr/pkg/include/uthash.h:151:3: note: in expansion of macro ?HASH_FUNCTION?
  151 |   HASH_FUNCTION(keyptr, keylen, hashv);                                          \
      |   ^~~~~~~~~~~~~
mvt.c:455:4: note: in expansion of macro ?HASH_VALUE?
  455 |    HASH_VALUE(&newvalue, size, hashv); \
      |    ^~~~~~~~~~
mvt.c:486:4: note: in expansion of macro ?MVT_PARSE_VALUE?
  486 |    MVT_PARSE_VALUE(sint_values_hash, \
      |    ^~~~~~~~~~~~~~~
mvt.c:503:2: note: in expansion of macro ?MVT_PARSE_INT_VALUE?
  503 |  MVT_PARSE_INT_VALUE(value); \
      |  ^~~~~~~~~~~~~~~~~~~
mvt.c:740:4: note: in expansion of macro ?MVT_PARSE_INT_DATUM?
  740 |    MVT_PARSE_INT_DATUM(int64_t, DatumGetInt64);
      |    ^~~~~~~~~~~~~~~~~~~
/usr/pkg/include/postgresql/server/utils/hsearch.h:98:23: error: called object is not a function or function pointer
   98 | #define HASH_FUNCTION 0x0040 /* Set user defined hash function */
      |                       ^~~~~~
/usr/pkg/include/uthash.h:151:3: note: in expansion of macro ?HASH_FUNCTION?
  151 |   HASH_FUNCTION(keyptr, keylen, hashv);                                          \
      |   ^~~~~~~~~~~~~
mvt.c:455:4: note: in expansion of macro ?HASH_VALUE?
  455 |    HASH_VALUE(&newvalue, size, hashv); \
      |    ^~~~~~~~~~
mvt.c:497:3: note: in expansion of macro ?MVT_PARSE_VALUE?
  497 |   MVT_PARSE_VALUE(hash, value, size, pfvaluefield, pftype); \
      |   ^~~~~~~~~~~~~~~
mvt.c:743:4: note: in expansion of macro ?MVT_PARSE_DATUM?
  743 |    MVT_PARSE_DATUM(float,
      |    ^~~~~~~~~~~~~~~
/usr/pkg/include/postgresql/server/utils/hsearch.h:98:23: error: called object is not a function or function pointer
   98 | #define HASH_FUNCTION 0x0040 /* Set user defined hash function */
      |                       ^~~~~~
/usr/pkg/include/uthash.h:151:3: note: in expansion of macro ?HASH_FUNCTION?
  151 |   HASH_FUNCTION(keyptr, keylen, hashv);                                          \
      |   ^~~~~~~~~~~~~
mvt.c:455:4: note: in expansion of macro ?HASH_VALUE?
  455 |    HASH_VALUE(&newvalue, size, hashv); \
      |    ^~~~~~~~~~
mvt.c:497:3: note: in expansion of macro ?MVT_PARSE_VALUE?
  497 |   MVT_PARSE_VALUE(hash, value, size, pfvaluefield, pftype); \
      |   ^~~~~~~~~~~~~~~
mvt.c:751:4: note: in expansion of macro ?MVT_PARSE_DATUM?
  751 |    MVT_PARSE_DATUM(double,
      |    ^~~~~~~~~~~~~~~
gmake[1]: *** [<builtin>: mvt.o] Error 1
gmake[1]: Leaving directory '/n0/gdt/SOFTWARE/GEO/POSTGIS/postgis/postgis'
gmake: *** [GNUmakefile:36: all] Error 1


From gdt at lexort.com  Sat Jun  6 11:06:34 2026
From: gdt at lexort.com (Greg Troxel)
Date: Sat, 06 Jun 2026 14:06:34 -0400
Subject: 3.6.4 Release
In-Reply-To: <74FFEE50-9577-4B87-ACC2-6396ED39C8FB@cleverelephant.ca> (Paul
 Ramsey's message of "Fri, 5 Jun 2026 16:49:29 -0700")
References: <74FFEE50-9577-4B87-ACC2-6396ED39C8FB@cleverelephant.ca>
Message-ID: <rmiv7bvtufp.fsf@s1.lexort.com>

This is very likely not new, and I don't mean to demand that anybody fix
it, but there's a lot of UB around ctype(3) functions.  The allowable
values of arugments is very narrow.    POSIX says for isalpha (the rest
have the same rules):

  The c argument is an int, the value of which the application shall
  ensure is representable as an unsigned char or equal to the value of
  the macro EOF. If the argument has any other value, the behavior is
  undefined.

https://pubs.opengroup.org/onlinepubs/9799919799/functions/isalpha.html

The problem is passing "char" to one of these functions.   Yes, I can
totally see why that's obviously ok -- except it isn't :-(.

The short form:

optionlist.c:36:18: warning: array subscript has type 'char' [-Wchar-subscripts]
lwin_wkt.c:91:36: warning: array subscript has type 'char' [-Wchar-subscripts]
lwalgorithm.c:697:27: warning: array subscript has type 'char' [-Wchar-subscripts]
lwgeom_box.c:68:24: warning: array subscript has type ?char? [-Wchar-subscripts]
lwgeom_geos_predicates.c:923:21: warning: array subscript has type ?char? [-Wchar-subscripts]
lwgeom_in_gml.c:514:17: warning: array subscript has type ?char? [-Wchar-subscripts]
lwgeom_in_gml.c:561:35: warning: array subscript has type ?char? [-Wchar-subscripts]
lwgeom_in_gml.c:565:15: warning: array subscript has type ?char? [-Wchar-subscripts]
lwgeom_in_gml.c:589:20: warning: array subscript has type ?char? [-Wchar-subscripts]
lwgeom_in_gml.c:669:17: warning: array subscript has type ?char? [-Wchar-subscripts]
lwgeom_in_gml.c:673:15: warning: array subscript has type ?char? [-Wchar-subscripts]
lwgeom_in_gml.c:809:20: warning: array subscript has type ?char? [-Wchar-subscripts]
lwgeom_in_gml.c:816:21: warning: array subscript has type ?char? [-Wchar-subscripts]
lwgeom_in_gml.c:880:17: warning: array subscript has type ?char? [-Wchar-subscripts]
lwgeom_in_gml.c:883:15: warning: array subscript has type ?char? [-Wchar-subscripts]
lwgeom_in_kml.c:332:24: warning: array subscript has type ?char? [-Wchar-subscripts]
lwgeom_in_kml.c:336:18: warning: array subscript has type ?char? [-Wchar-subscripts]
lwgeom_in_kml.c:353:30: warning: array subscript has type ?char? [-Wchar-subscripts]
lwgeom_in_kml.c:358:30: warning: array subscript has type ?char? [-Wchar-subscripts]
lwgeom_in_kml.c:359:22: warning: array subscript has type ?char? [-Wchar-subscripts]
lwgeom_in_kml.c:371:40: warning: array subscript has type ?char? [-Wchar-subscripts]
lwgeom_in_marc21.c:153:23: warning: array subscript has type ?char? [-Wchar-subscripts]



trying to trim the log to these issues:




---- Making all in liblwgeom
libtool: compile:  gcc -I./../deps/ryu/.. -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include/libxml2 -I/usr/pkg/include -I/usr/pkg/include/json-c -I/usr/pkg/include -DNDEBUG -I. -I. -std=gnu11 -g -O2 -fno-math-errno -fno-signed-zeros -Wall -O2 -fPIC -DPIC -c optionlist.c  -fPIC -DPIC -o .libs/optionlist.o
In file included from /usr/include/ctype.h:100,
                 from optionlist.c:28:
optionlist.c: In function 'option_list_string_to_lower':
optionlist.c:36:18: warning: array subscript has type 'char' [-Wchar-subscripts]
   36 |   *key = tolower(*key);
      |                  ^
libtool: compile:  gcc -I./../deps/ryu/.. -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include/libxml2 -I/usr/pkg/include -I/usr/pkg/include/json-c -I/usr/pkg/include -DNDEBUG -I. -I. -std=gnu11 -g -O2 -fno-math-errno -fno-signed-zeros -Wall -O2 -fPIC -DPIC -c lwin_wkt.c  -fPIC -DPIC -o .libs/lwin_wkt.o
In file included from /usr/include/ctype.h:100,
                 from lwin_wkt.c:27:
lwin_wkt.c: In function 'wkt_dimensionality':
lwin_wkt.c:91:36: warning: array subscript has type 'char' [-Wchar-subscripts]
   91 |   else if( ! isspace(dimensionality[i]) ) break;
      |                                    ^
libtool: compile:  gcc -I./../deps/ryu/.. -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include/libxml2 -I/usr/pkg/include -I/usr/pkg/include/json-c -I/usr/pkg/include -DNDEBUG -I. -I. -std=gnu11 -g -O2 -fno-math-errno -fno-signed-zeros -Wall -O2 -fPIC -DPIC -c lwalgorithm.c  -fPIC -DPIC -o .libs/lwalgorithm.o
In file included from /usr/include/ctype.h:100,
                 from lwalgorithm.c:28:
lwalgorithm.c: In function 'decode_geohash_bbox':
lwalgorithm.c:697:27: warning: array subscript has type 'char' [-Wchar-subscripts]
  697 |   char c = tolower(geohash[i]);
      |                           ^

---- Making all in postgis
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -O2 -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2 -I/usr/include/readline -I/usr/pkg/include -fPIC -DPIC -fvisibility=hidden -I../liblwgeom -I../liblwgeom -std=gnu11 -g -O2 -fno-math-errno -fno-signed-zeros -Wall -O2 -I../libpgcommon -I../deps/flatgeobuf -I../deps/wagyu -I../deps/uthash/include  -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include/libxml2  -I/usr/pkg/include -I/usr/pkg/include/json-c -I/usr/pkg/include -DNDEBUG   -fPIC -DPIC -I. -I./ -I/usr/pkg/include/postgresql/server -I/usr/pkg/include/postgresql/internal -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2 -I/usr/include/readline -I/usr/pkg/include  -I/usr/pkg/include/libxml2 -I/usr/pkg/include -I/usr/pkg/include  -c -o lwgeom_box.o lwgeom_box.c
In file included from /usr/include/ctype.h:100,
                 from /usr/pkg/include/postgresql/server/port.h:16,
                 from /usr/pkg/include/postgresql/server/c.h:1385,
                 from /usr/pkg/include/postgresql/server/postgres.h:45,
                 from lwgeom_box.c:27:
lwgeom_box.c: In function ?BOX2D_in?:
lwgeom_box.c:68:24: warning: array subscript has type ?char? [-Wchar-subscripts]
   68 |    str[i] = tolower(str[i]);
      |                        ^
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -O2 -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2 -I/usr/include/readline -I/usr/pkg/include -fPIC -DPIC -fvisibility=hidden -I../liblwgeom -I../liblwgeom -std=gnu11 -g -O2 -fno-math-errno -fno-signed-zeros -Wall -O2 -I../libpgcommon -I../deps/flatgeobuf -I../deps/wagyu -I../deps/uthash/include  -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include/libxml2  -I/usr/pkg/include -I/usr/pkg/include/json-c -I/usr/pkg/include -DNDEBUG   -fPIC -DPIC -I. -I./ -I/usr/pkg/include/postgresql/server -I/usr/pkg/include/postgresql/internal -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2 -I/usr/include/readline -I/usr/pkg/include  -I/usr/pkg/include/libxml2 -I/usr/pkg/include -I/usr/pkg/include  -c -o lwgeom_geos_predicates.o lwgeom_geos_predicates.c
In file included from /usr/include/ctype.h:100,
                 from /usr/pkg/include/postgresql/server/port.h:16,
                 from /usr/pkg/include/postgresql/server/c.h:1385,
                 from /usr/pkg/include/postgresql/server/postgres.h:45,
                 from lwgeom_geos_predicates.c:31:
lwgeom_geos_predicates.c: In function ?relate_pattern?:
lwgeom_geos_predicates.c:923:21: warning: array subscript has type ?char? [-Wchar-subscripts]
  923 |   im[i] = toupper(im[i]);
      |                     ^
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -O2 -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2 -I/usr/include/readline -I/usr/pkg/include -fPIC -DPIC -fvisibility=hidden -I../liblwgeom -I../liblwgeom -std=gnu11 -g -O2 -fno-math-errno -fno-signed-zeros -Wall -O2 -I../libpgcommon -I../deps/flatgeobuf -I../deps/wagyu -I../deps/uthash/include  -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include/libxml2  -I/usr/pkg/include -I/usr/pkg/include/json-c -I/usr/pkg/include -DNDEBUG   -fPIC -DPIC -I. -I./ -I/usr/pkg/include/postgresql/server -I/usr/pkg/include/postgresql/internal -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2 -I/usr/include/readline -I/usr/pkg/include  -I/usr/pkg/include/libxml2 -I/usr/pkg/include -I/usr/pkg/include  -c -o lwgeom_in_gml.o lwgeom_in_gml.c
In file included from /usr/include/ctype.h:100,
                 from /usr/pkg/include/postgresql/server/port.h:16,
                 from /usr/pkg/include/postgresql/server/c.h:1385,
                 from /usr/pkg/include/postgresql/server/postgres.h:45,
                 from lwgeom_in_gml.c:49:
lwgeom_in_gml.c: In function ?parse_gml_srs?:
lwgeom_in_gml.c:514:17: warning: array subscript has type ?char? [-Wchar-subscripts]
  514 |    if (!isdigit(*p)) gml_lwpgerror("unknown spatial reference system", 5);
      |                 ^
lwgeom_in_gml.c: In function ?parse_gml_double?:
lwgeom_in_gml.c:561:35: warning: array subscript has type ?char? [-Wchar-subscripts]
  561 |  if (space_before) while (isspace(*d)) d++;
      |                                   ^
lwgeom_in_gml.c:565:15: warning: array subscript has type ?char? [-Wchar-subscripts]
  565 |   if (isdigit(*p))
      |               ^
lwgeom_in_gml.c:589:20: warning: array subscript has type ?char? [-Wchar-subscripts]
  589 |   else if (isspace(*p))
      |                    ^
lwgeom_in_gml.c: In function ?parse_gml_coordinates?:
lwgeom_in_gml.c:669:17: warning: array subscript has type ?char? [-Wchar-subscripts]
  669 |  while (isspace(*p)) p++;  /* Eat extra whitespaces if any */
      |                 ^
lwgeom_in_gml.c:673:15: warning: array subscript has type ?char? [-Wchar-subscripts]
  673 |   if (isdigit(*p)) digit = true; /* One state parser */
      |               ^
lwgeom_in_gml.c: In function ?parse_gml_pos?:
lwgeom_in_gml.c:809:20: warning: array subscript has type ?char? [-Wchar-subscripts]
  809 |     while (isspace(*pos)) pos++; /* Eat extra whitespaces if any */
      |                    ^
lwgeom_in_gml.c:816:21: warning: array subscript has type ?char? [-Wchar-subscripts]
  816 |         if (isdigit(*pos)) digit = true;
      |                     ^
lwgeom_in_gml.c: In function ?parse_gml_poslist?:
lwgeom_in_gml.c:880:17: warning: array subscript has type ?char? [-Wchar-subscripts]
  880 |  while (isspace(*poslist)) poslist++; /* Eat extra whitespaces if any */
      |                 ^
lwgeom_in_gml.c:883:15: warning: array subscript has type ?char? [-Wchar-subscripts]
  883 |   if (isdigit(*poslist)) digit = true;
      |               ^
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -O2 -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2 -I/usr/include/readline -I/usr/pkg/include -fPIC -DPIC -fvisibility=hidden -I../liblwgeom -I../liblwgeom -std=gnu11 -g -O2 -fno-math-errno -fno-signed-zeros -Wall -O2 -I../libpgcommon -I../deps/flatgeobuf -I../deps/wagyu -I../deps/uthash/include  -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include/libxml2  -I/usr/pkg/include -I/usr/pkg/include/json-c -I/usr/pkg/include -DNDEBUG   -fPIC -DPIC -I. -I./ -I/usr/pkg/include/postgresql/server -I/usr/pkg/include/postgresql/internal -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2 -I/usr/include/readline -I/usr/pkg/include  -I/usr/pkg/include/libxml2 -I/usr/pkg/include -I/usr/pkg/include  -c -o lwgeom_in_kml.o lwgeom_in_kml.c
In file included from /usr/include/ctype.h:100,
                 from /usr/pkg/include/postgresql/server/port.h:16,
                 from /usr/pkg/include/postgresql/server/c.h:1385,
                 from /usr/pkg/include/postgresql/server/postgres.h:45,
                 from lwgeom_in_kml.c:40:
lwgeom_in_kml.c: In function ?parse_kml_coordinates?:
lwgeom_in_kml.c:332:24: warning: array subscript has type ?char? [-Wchar-subscripts]
  332 |   while (*p && isspace(*p)) ++p;
      |                        ^
lwgeom_in_kml.c:336:18: warning: array subscript has type ?char? [-Wchar-subscripts]
  336 |     if ( isdigit(*p) || *p == '+' || *p == '-' || *p == '.' ) {
      |                  ^
lwgeom_in_kml.c:353:30: warning: array subscript has type ?char? [-Wchar-subscripts]
  353 |         if ( *q && ! isspace(*q) && *q != ',' ) {
      |                              ^
lwgeom_in_kml.c:358:30: warning: array subscript has type ?char? [-Wchar-subscripts]
  358 |         while (*q && isspace(*q)) ++q;
      |                              ^
lwgeom_in_kml.c:359:22: warning: array subscript has type ?char? [-Wchar-subscripts]
  359 |         if ( isdigit(*q) || *q == '+' || *q == '-' || *q == '.' || ! *q ) {
      |                      ^
lwgeom_in_kml.c:371:40: warning: array subscript has type ?char? [-Wchar-subscripts]
  371 |     } else if ( *p != ',' && ! isspace(*p) ) {
      |                                        ^
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -O2 -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2 -I/usr/include/readline -I/usr/pkg/include -fPIC -DPIC -fvisibility=hidden -I../liblwgeom -I../liblwgeom -std=gnu11 -g -O2 -fno-math-errno -fno-signed-zeros -Wall -O2 -I../libpgcommon -I../deps/flatgeobuf -I../deps/wagyu -I../deps/uthash/include  -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include/libxml2  -I/usr/pkg/include -I/usr/pkg/include/json-c -I/usr/pkg/include -DNDEBUG   -fPIC -DPIC -I. -I./ -I/usr/pkg/include/postgresql/server -I/usr/pkg/include/postgresql/internal -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2 -I/usr/include/readline -I/usr/pkg/include  -I/usr/pkg/include/libxml2 -I/usr/pkg/include -I/usr/pkg/include  -c -o lwgeom_in_marc21.o lwgeom_in_marc21.c
In file included from /usr/include/ctype.h:100,
                 from /usr/pkg/include/postgresql/server/port.h:16,
                 from /usr/pkg/include/postgresql/server/c.h:1385,
                 from /usr/pkg/include/postgresql/server/postgres.h:45,
                 from lwgeom_in_marc21.c:21:
lwgeom_in_marc21.c: In function ?is_literal_valid?:
lwgeom_in_marc21.c:153:23: warning: array subscript has type ?char? [-Wchar-subscripts]
  153 |   if (!isdigit(literal[j])) {
      |                       ^

From gdt at lexort.com  Sat Jun  6 11:30:42 2026
From: gdt at lexort.com (Greg Troxel)
Date: Sat, 06 Jun 2026 14:30:42 -0400
Subject: 3.6.4 Release
In-Reply-To: <rmi4ijfv9dh.fsf@s1.lexort.com> (Greg Troxel's message of "Sat,
 06 Jun 2026 13:58:34 -0400")
References: <74FFEE50-9577-4B87-ACC2-6396ED39C8FB@cleverelephant.ca>
 <rmi4ijfv9dh.fsf@s1.lexort.com>
Message-ID: <rmijysbttbh.fsf@s1.lexort.com>

Greg Troxel <gdt at lexort.com> writes:

> gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -O2 -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2 -I/usr/include/readline -I/usr/pkg/include -fPIC -DPIC -fvisibility=hidden -I../liblwgeom -I../liblwgeom -std=gnu11 -g -O2 -fno-math-errno -fno-signed-zeros -Wall -O2 -I../libpgcommon -I../deps/flatgeobuf -I../deps/wagyu -I../deps/uthash/include  -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include/libxml2  -I/usr/pkg/include -I/usr/pkg/include/json-c -I/usr/pkg/include -DNDEBUG   -fPIC -DPIC -I. -I./ -I/usr/pkg/include/postgresql/server -I/usr/pkg/include/postgresql/internal -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2 -I/usr/include/readline -I/usr/pkg/include  -I/usr/pkg/include/libxml2 -I/usr/pkg/include -I/usr/pkg/include  -c -o mvt.o mvt.c
> In file included from /usr/pkg/include/postgresql/server/storage/shmem.h:24,
>                  from /usr/pkg/include/postgresql/server/storage/lock.h:25,
>                  from /usr/pkg/include/postgresql/server/catalog/namespace.h:18,
>                  from mvt.h:35,
>                  from mvt.c:30:
> mvt.c: In function ?get_key_index_with_size?:
> /usr/pkg/include/postgresql/server/utils/hsearch.h:98:23: error: called object is not a function or function pointer
>    98 | #define HASH_FUNCTION 0x0040 /* Set user defined hash function */
>       |                       ^~~~~~

Building 3.6.3 in pkgsrc does not have this issue, and thus I think it's
either caused or provoked by my build environment.

From lr at pcorp.us  Sat Jun  6 14:51:08 2026
From: lr at pcorp.us (Regina Obe)
Date: Sat, 6 Jun 2026 17:51:08 -0400
Subject: 3.6.4 Release
In-Reply-To: <74FFEE50-9577-4B87-ACC2-6396ED39C8FB@cleverelephant.ca>
References: <74FFEE50-9577-4B87-ACC2-6396ED39C8FB@cleverelephant.ca>
Message-ID: <001401dcf5fe$96685330$c338f990$@pcorp.us>

+1

> -----Original Message-----
> From: Paul Ramsey <pramsey at cleverelephant.ca>
> Sent: Friday, June 5, 2026 7:49 PM
> To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
> Subject: 3.6.4 Release
> 
> While we do not have a lot of changes since the last release, we do have
an
> important fix to upgrading which resolves (mitigates) a long-time issue
with
> SRID lookup during upgrade, as well as a security patch which I would like
to
> put to bed.  Since there will be a lot of PostGIS packages cut over the
summer
> I would like those packages to have these changes.
> 
> +1 (numbers are cheap)
> 
> P=


From me at komzpa.net  Sun Jun  7 19:17:46 2026
From: me at komzpa.net (=?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?=)
Date: Mon, 8 Jun 2026 06:17:46 +0400
Subject: h3-pg 4.5.0 released
Message-ID: <CAC8Q8tKWdi+sbXq1MvkMM7Rppd7uUnGyPp-f4Q8O5tDbOnCQJw@mail.gmail.com>

h3-pg 4.5.0 is released. This is the first h3-pg release under the PostGIS
umbrella.

h3-pg provides PostgreSQL bindings for the H3 hierarchical
hexagonal geospatial indexing library, with optional PostGIS integration
through the h3_postgis extension.

Details here:

https://github.com/postgis/h3-pg/releases/tag/v4.5.0

The release is also available on PGXN:

https://pgxn.org/dist/h3/

Highlights include bundled H3 core 4.5.0, new bindings for newer upstream
H3  APIs, GiST operator class work for h3index, PostgreSQL 17+
maintenance-operation  fixes, SP-GiST fixes, and improved h3_postgis
geometry/polygonization behavior.

Please report issues by replying to this email or reporting them on GitHub:

https://github.com/postgis/h3-pg/issues

Thanks,
Darafei
PostGIS Development Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260608/9316200e/attachment.htm>

From gdt at lexort.com  Mon Jun  8 07:57:28 2026
From: gdt at lexort.com (Greg Troxel)
Date: Mon, 08 Jun 2026 10:57:28 -0400
Subject: 3.6.4 Release
In-Reply-To: <74FFEE50-9577-4B87-ACC2-6396ED39C8FB@cleverelephant.ca> (Paul
 Ramsey's message of "Fri, 5 Jun 2026 16:49:29 -0700")
References: <74FFEE50-9577-4B87-ACC2-6396ED39C8FB@cleverelephant.ca>
Message-ID: <rmifr2xozaf.fsf@s1.lexort.com>

Following up on the HASH_FUNCTION problem:

In

  /usr/pkg/include/postgresql/server/utils/hsearch.h

there is

  /* Flag bits for hash_create; most indicate which parameters are supplied */
  #define HASH_FUNCTION   0x0040  /* Set user defined hash function */

In

  /usr/pkg/include/uthash.h

there is

  #ifndef HASH_FUNCTION
  #define HASH_FUNCTION(keyptr,keylen,hashv) HASH_JEN(keyptr, keylen, hashv)
  #endif


Which explains the build errors.

I have

  postgresql16-server-16.14

which does not seem out-of-spec or at all odd.

I don't understand why others aren't seeing this, even if I haven't
figured out how hsearch.h is included in mvt.c.

It might be via

  postgis/lwgeom_geos_prepared.h:#include "utils/hsearch.h"

From pramsey at cleverelephant.ca  Mon Jun  8 10:27:29 2026
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Mon, 8 Jun 2026 10:27:29 -0700
Subject: 3.6.4 Release
In-Reply-To: <rmifr2xozaf.fsf@s1.lexort.com>
References: <74FFEE50-9577-4B87-ACC2-6396ED39C8FB@cleverelephant.ca>
 <rmifr2xozaf.fsf@s1.lexort.com>
Message-ID: <CACowWR08vsMCR_4Lq80G4ky8ZoFcS+hJ5N7TaOsuBd3EVqkbug@mail.gmail.com>

On Mon, Jun 8, 2026 at 7:57?AM Greg Troxel <gdt at lexort.com> wrote:
>
> It might be via
>
>   postgis/lwgeom_geos_prepared.h:#include "utils/hsearch.h"

I don't know that this will fix anything, since that header is needed
in other places, but in that particular location it's not used as far
as I can see, so I have pulled it out.

P.

From strk at kbt.io  Mon Jun  8 10:35:33 2026
From: strk at kbt.io (Sandro Santilli)
Date: Mon, 8 Jun 2026 19:35:33 +0200
Subject: PSC Vote: PostGIS 3.7.0 beta1
In-Reply-To: <000401dcf204$d34a38c0$79deaa40$@pcorp.us>
References: <000401dcf204$d34a38c0$79deaa40$@pcorp.us>
Message-ID: <aib9ZRYqbyD9q81-@c19.localdomain>

On Mon, Jun 01, 2026 at 04:25:44PM -0400, Regina Obe wrote:
> I'd like to release a PostGIS 3.7.0 beta 1 soon say in about a week.
> PostgreSQL 19 beta1 is due out any moment.  So would be good to have people
> start testing PostGIS 3.7.0 beta1 along side it.
> 
> Are there any additional SQL API facing changes people are planning for that
> they haven't committed?
> 
> Anyway +1 from me for release.

+1 but I'd like to get the agentic coders file organization sorted out before we go final.

--strk;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260608/500114e6/attachment.sig>

From strk at kbt.io  Mon Jun  8 10:37:22 2026
From: strk at kbt.io (Sandro Santilli)
Date: Mon, 8 Jun 2026 19:37:22 +0200
Subject: 3.6.4 Release
In-Reply-To: <74FFEE50-9577-4B87-ACC2-6396ED39C8FB@cleverelephant.ca>
References: <74FFEE50-9577-4B87-ACC2-6396ED39C8FB@cleverelephant.ca>
Message-ID: <aib90hkiDKUOdSGM@c19.localdomain>

On Fri, Jun 05, 2026 at 04:49:29PM -0700, Paul Ramsey wrote:
> While we do not have a lot of changes since the last release, we do have an important fix to upgrading which resolves (mitigates) a long-time issue with SRID lookup during upgrade, as well as a security patch which I would like to put to bed.  Since there will be a lot of PostGIS packages cut over the summer I would like those packages to have these changes.
> 
> +1 (numbers are cheap)

+1

--strk;

  Libre GIS consultant/developer ?
  https://strk.kbt.io/services.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260608/152324f1/attachment-0001.sig>

From strk at kbt.io  Mon Jun  8 10:59:05 2026
From: strk at kbt.io (Sandro Santilli)
Date: Mon, 8 Jun 2026 19:59:05 +0200
Subject: Should agentic skill files be elsewhere ?
Message-ID: <aicC6Xw862yao3x1@c19.localdomain>

I noticed a skills/ directory was added, containing both postgis-specific
document and postgis-agnostic document.

The directory has no README file, but I learnt that such files are meant
to be read by AI-based coding agents, to pass them to LLM inference
tools as a "context".

My question is: do these files belong in the PostGIS code base ? I suspect no.

For comparison, the Gitea project uses a separate repository [1] for this,
I'd use the same approach.

A separate repository would have a proper README and could maybe also
have different set of skills for different scenarios, and different usage
instructions for different tools (I find it unfair that a single tool name
is referenced by these docs while there are a lot of tools out there).

So, what do you think about this ? I haven't found a thread in this list
discussing this addition, so here it is.

[1] https://gitea.com/gitea/gitea-tea-skill

-- 

  Libre GIS consultant/developer ?
  https://strk.kbt.io/services.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260608/431bc202/attachment.sig>

From pramsey at cleverelephant.ca  Mon Jun  8 11:01:06 2026
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Mon, 8 Jun 2026 11:01:06 -0700
Subject: Should agentic skill files be elsewhere ?
In-Reply-To: <aicC6Xw862yao3x1@c19.localdomain>
References: <aicC6Xw862yao3x1@c19.localdomain>
Message-ID: <BDF2EBD9-66E7-4D07-90FD-00B47600FEEC@cleverelephant.ca>

I am not sure what the best practice actually is on these files.
I do know I was a little nonplussed to read it and find it spelling out in specificity a development setup that? was nothing like what I do, and therefore would lead any agent I happened to use absolutely astray. 

P

> On Jun 8, 2026, at 10:59?AM, Sandro Santilli <strk at kbt.io> wrote:
> 
> I noticed a skills/ directory was added, containing both postgis-specific
> document and postgis-agnostic document.
> 
> The directory has no README file, but I learnt that such files are meant
> to be read by AI-based coding agents, to pass them to LLM inference
> tools as a "context".
> 
> My question is: do these files belong in the PostGIS code base ? I suspect no.
> 
> For comparison, the Gitea project uses a separate repository [1] for this,
> I'd use the same approach.
> 
> A separate repository would have a proper README and could maybe also
> have different set of skills for different scenarios, and different usage
> instructions for different tools (I find it unfair that a single tool name
> is referenced by these docs while there are a lot of tools out there).
> 
> So, what do you think about this ? I haven't found a thread in this list
> discussing this addition, so here it is.
> 
> [1] https://gitea.com/gitea/gitea-tea-skill
> 
> -- 
> 
>  Libre GIS consultant/developer ?
>  https://strk.kbt.io/services.html


From gdt at lexort.com  Mon Jun  8 11:04:42 2026
From: gdt at lexort.com (Greg Troxel)
Date: Mon, 08 Jun 2026 14:04:42 -0400
Subject: 3.6.4 Release
In-Reply-To: <CACowWR08vsMCR_4Lq80G4ky8ZoFcS+hJ5N7TaOsuBd3EVqkbug@mail.gmail.com>
 (Paul Ramsey's message of "Mon, 8 Jun 2026 10:27:29 -0700")
References: <74FFEE50-9577-4B87-ACC2-6396ED39C8FB@cleverelephant.ca>
 <rmifr2xozaf.fsf@s1.lexort.com>
 <CACowWR08vsMCR_4Lq80G4ky8ZoFcS+hJ5N7TaOsuBd3EVqkbug@mail.gmail.com>
Message-ID: <rmijys8oqmd.fsf@s1.lexort.com>

Thanks.  I updated from git and still have

  gmake[1]: Entering directory '/n0/gdt/SOFTWARE/GEO/POSTGIS/postgis/BUILD/postgis'
  gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -O2 -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2 -I/usr/include/readline -I/usr/pkg/include -fPIC -DPIC -fvisibility=hidden -I../../liblwgeom -I../liblwgeom -std=gnu11 -g -O2 -fno-math-errno -fno-signed-zeros -Wall -O2 -I../../libpgcommon -I../../deps/flatgeobuf -I../../deps/wagyu -I../../deps/uthash/include  -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include/libxml2  -I/usr/pkg/include -I/usr/pkg/include/json-c -I/usr/pkg/include -DNDEBUG   -fPIC -DPIC -I. -I./ -I/usr/pkg/include/postgresql/server -I/usr/pkg/include/postgresql/internal -Dz_off_t=long -I/usr/include -I/usr/pkg/include/libxml2 -I/usr/include/readline -I/usr/pkg/include  -I/usr/pkg/include/libxml2 -I/usr/pkg/include -I/usr/pkg/include  -c -o mvt.o ../../postgis/mvt.c
  In file included from /usr/pkg/include/postgresql/server/storage/shmem.h:24,
                   from /usr/pkg/include/postgresql/server/storage/lock.h:25,
                   from /usr/pkg/include/postgresql/server/catalog/namespace.h:18,
                   from ../../postgis/mvt.h:35,
                   from ../../postgis/mvt.c:30:
  ../../postgis/mvt.c: In function ?get_key_index_with_size?:
  /usr/pkg/include/postgresql/server/utils/hsearch.h:98:23: error: called object is not a function or function pointer
     98 | #define HASH_FUNCTION 0x0040 /* Set user defined hash function */
        |                       ^~~~~~
  /usr/pkg/include/uthash.h:151:3: note: in expansion of macro ?HASH_FUNCTION?
    151 |   HASH_FUNCTION(keyptr, keylen, hashv);                                          \
        |   ^~~~~~~~~~~~~

so it looks like pgsql itself -- or at least my build -- exposes all of
utils/hsearch.h, when someone includes catalog/namespace.h.  I traced
the include chain and code reading matches the error message.


I see now that the problem is that postgis has a vendored copy of
uthash, and it's been modified rename HASH_FUNCTION to UTHASH_FUNCTION
(or something like that), but that hasn't been pushed upstream to
uthash, or they rejected it.  Really, both uthash and pgsql using
HASH_FUNCTION in a public header is a namespace pollution issues -- both
should be prefixed/etc. somehow.

The postgis package does not depend on uthash, so the compiler doesn't
see those files when building.
I suspect I just didn't have uthash installed the times I previously
built postgis from git.

I removed the uthash package, and then the build went ok (with ctype UB
warnings).


So there's nothing to be done for 3.6.4 -- I'm now confident this is not
new.

From gdt at lexort.com  Mon Jun  8 11:13:16 2026
From: gdt at lexort.com (Greg Troxel)
Date: Mon, 08 Jun 2026 14:13:16 -0400
Subject: Should agentic skill files be elsewhere ?
In-Reply-To: <aicC6Xw862yao3x1@c19.localdomain> (Sandro Santilli's message of
 "Mon, 8 Jun 2026 19:59:05 +0200")
References: <aicC6Xw862yao3x1@c19.localdomain>
Message-ID: <rmicxy0oq83.fsf@s1.lexort.com>

Sandro Santilli <strk at kbt.io> writes:

> My question is: do these files belong in the PostGIS code base ? I suspect no.

My gut is no.  To the extent it's about SQL and not postgis, definitely
not.  To the extent it's about best practices for writing postgis sql,
that belongs in the documentation, written for humans.


There's a higher-level question of postgis's policy is on LLM output.
Probably most of you are aware of gdal's experiment, deciding to allow
LLM PRs as long as they are reviewed/understood by the human submitter.
That went badly, leading to more or less "no LLM content at all", with a
thought that mechanical changes by a seasoned contributor might be ok.
So far, CONTRIBUTING.md doesn't say.

From strk at kbt.io  Tue Jun  9 02:36:10 2026
From: strk at kbt.io (Sandro Santilli)
Date: Tue, 9 Jun 2026 11:36:10 +0200
Subject: Should agentic skill files be elsewhere ?
In-Reply-To: <BDF2EBD9-66E7-4D07-90FD-00B47600FEEC@cleverelephant.ca>
References: <aicC6Xw862yao3x1@c19.localdomain>
 <BDF2EBD9-66E7-4D07-90FD-00B47600FEEC@cleverelephant.ca>
Message-ID: <aifeiqTpJuNeOiYs@c19.localdomain>

On Mon, Jun 08, 2026 at 11:01:06AM -0700, Paul Ramsey wrote:

> I do know I was a little nonplussed to read it and find it spelling out
> in specificity a development setup that? was nothing like what I do,
> and therefore would lead any agent I happened to use absolutely astray.

That spelling is also present in AGENTS.md since its introduction
in commit d7c5ead4d9998d34b6a7753bf757981ffdefb326 (Sat Oct 18 00:15:20 2025 +0400)

The file format is documented in https://agents.md/, which rightfully
doesn't mention a specific tool, so I'd be in favor of steering that
file ALSO in a way that is more open-source and local-inference-first
friendly.

Darafai: what do you think ? Since it was you introducing both AGENTS.md
and the skill/s directory, I'd prefer if was you driving any change.

--strk;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260609/ce9ddaba/attachment.sig>

From strk at kbt.io  Tue Jun  9 02:37:19 2026
From: strk at kbt.io (Sandro Santilli)
Date: Tue, 9 Jun 2026 11:37:19 +0200
Subject: Should agentic skill files be elsewhere ?
In-Reply-To: <rmicxy0oq83.fsf@s1.lexort.com>
References: <aicC6Xw862yao3x1@c19.localdomain> <rmicxy0oq83.fsf@s1.lexort.com>
Message-ID: <aifezyqFoMLL4wrq@c19.localdomain>

On Mon, Jun 08, 2026 at 02:13:16PM -0400, Greg Troxel wrote:
> 
> There's a higher-level question of postgis's policy is on LLM output.

This conversation probably warrants a separate thread.

--strk;

  Libre GIS consultant/developer ?
  https://strk.kbt.io/services.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260609/4822191d/attachment.sig>

From gdt at lexort.com  Tue Jun  9 03:16:38 2026
From: gdt at lexort.com (Greg Troxel)
Date: Tue, 09 Jun 2026 06:16:38 -0400
Subject: LLM policy
Message-ID: <rmiv7bsj9x5.fsf@s1.lexort.com>

A human recently told me to make this a new thread :-)

Recently qgis and gdal have discussed and adopted policy about
LLM-generated content in mostly PRs.

After "human must be in control and really understand" was agreed to in
gdal, somewhat (in my fuzzy view) as a compromise between the "just no"
camps and those that were somewhat more welcoming, somewhat as an
interim, a new policy of pretty much "just no" (except for fancy
autocomplete by those with clue) was proposed and adopted.  Basic issues
were limited human maintainer bandwidth, humans not being happy about
interacting with machines, and code that looks very plausible but isn't
quite right, in a way that's very hard to identify.

qgis policy:

  https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md

revised gdal policy, after a brief experiment with a policy like qgis's:

  https://gdal.org/en/stable/community/ai_tool_policy.html


My own experience was in seeing hamlib (not geo) get a vibe-coded PR
while talking about policy, and I and several others reviewed it.  Both
code and PR text were very wordy, in a way that wasn't helpful, and in
the end we decided the PR was off base.  But it took a lot of time, it
was hard to determine if it was right or not, and a (trained software
engineer) human would have made much smaller changes and explained them
far more concisely.  This experiment left me thinking that it wasn't ok
to ask humans to review, read, or otherwise deal with LLM output.

Thus, I favor the gdal approach.  I suspect that after a few vibe-coded
PRs, those reviewing them will prefer that too.

Regardless of how the consensus ends up, postgis should state the rules
in CONTRIBUTING, and IMHO the rules should include up-front disclosure
of *any* LLM use in making a contribution, beyond the human contributor
gaining understanding.

From me at komzpa.net  Tue Jun  9 04:56:30 2026
From: me at komzpa.net (=?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?=)
Date: Tue, 9 Jun 2026 15:56:30 +0400
Subject: Should agentic skill files be elsewhere ?
In-Reply-To: <aifeiqTpJuNeOiYs@c19.localdomain>
References: <aicC6Xw862yao3x1@c19.localdomain>
 <BDF2EBD9-66E7-4D07-90FD-00B47600FEEC@cleverelephant.ca>
 <aifeiqTpJuNeOiYs@c19.localdomain>
Message-ID: <CAC8Q8tLn5a+cDfw=CmD61o5ZqKj0jtm+LWhK_faQaSnti0D3uQ@mail.gmail.com>

Hi,

First, about why it is like this now.

AGENTS.md: I set it up like this when making web-based hosted `codex` to
cleanly implement tasks. It starts with almost empty docker every time and
if you don't steer it to install dependencies or run tests it tends to skip
those and leave fixes half baked. This is what protects postgis from a
storm of bad AI PRs.

skills: started from
https://lists.osgeo.org/pipermail/postgis-devel/2025-November/030663.html
where Mat Arye requested the input on the skills of postgis to be included
into their pg-aiguide mcp. I've pulled up the postgis-related AGENTS lines
that I have on my production workflows and added it there. Later they had
feedback that some of it was overlapping the postgres skills they have
elsewhere, thus the split.

Now, the concerns I heard:

 - Paul's concern is that AGENTS is too specific. I agree it might be, but
it did not cause any problems for me so far - it clearly marks assumptions
at the top and agents nowadays (7 months is a lot of time...) seem smart
enough to see if it's not their precise case. What happens in practice is
that it skips over the parts of installing dependencies if they're
available through other means and on the developer machine that ends up
fine. If you have observed actual issues, I'd be happy to adjust it.

 - Sandro's concern that skills need to be moved elsewhere. I agree here
that location is up for discussion. In general, it is no different from the
docs and probably can live under docs.

The reason we need separate "kind" of docs for LLMs is because they are
different kind of consumer: normal users "don't know anything" when
starting to work with PostGIS and need basic introduction. LLMs "have seen
it all" around the internet, and instead need to rapidly unlearn the bad
and obsolete examples and be guided toward latest best practices, while
specifically calling out the ones replaced by it. There's too many
ST_Buffer(geom,0) on the internet to get it to pick ST_MakeValid as a first
option without it. I think it may be useful for humans too, as a cheat
sheet or something like that.

I don't think it belongs in a separate repo any more than docs belong to a
separate repo (and I hope this will not trigger "let's move docs out to
separate repo").

Another thing that may be useful to get raised: how tied are we to having
docs as xml? I think gdal moved to rst and it has made it a little easier
to navigate the sources of the docs on the file level.

Thanks,
Darafei.


On Tue, Jun 9, 2026 at 1:36?PM Sandro Santilli <strk at kbt.io> wrote:

> On Mon, Jun 08, 2026 at 11:01:06AM -0700, Paul Ramsey wrote:
>
> > I do know I was a little nonplussed to read it and find it spelling out
> > in specificity a development setup that? was nothing like what I do,
> > and therefore would lead any agent I happened to use absolutely astray.
>
> That spelling is also present in AGENTS.md since its introduction
> in commit d7c5ead4d9998d34b6a7753bf757981ffdefb326 (Sat Oct 18 00:15:20
> 2025 +0400)
>
> The file format is documented in https://agents.md/, which rightfully
> doesn't mention a specific tool, so I'd be in favor of steering that
> file ALSO in a way that is more open-source and local-inference-first
> friendly.
>
> Darafai: what do you think ? Since it was you introducing both AGENTS.md
> and the skill/s directory, I'd prefer if was you driving any change.
>
> --strk;
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260609/20443e62/attachment-0001.htm>

From me at komzpa.net  Tue Jun  9 06:10:51 2026
From: me at komzpa.net (=?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?=)
Date: Tue, 9 Jun 2026 17:10:51 +0400
Subject: LLM policy
In-Reply-To: <rmiv7bsj9x5.fsf@s1.lexort.com>
References: <rmiv7bsj9x5.fsf@s1.lexort.com>
Message-ID: <CAC8Q8t+bdsivBS-=5v25s-GC4g7oTZfKhXT-Bqmb_yQkGYB2iw@mail.gmail.com>

Hi,

I believe AIs are covered by existing diversity statement of code of
conduct:

https://postgis.net/community/conduct/#diversity-statement
> PostGIS welcomes and encourages participation by everyone. We are
committed to being a community that everyone feels good about joining, and
we will always work to treat everyone well. No matter how you identify
yourself or how others perceive you: we welcome you.

I don't think it is limited to "humans only" (assume LLMs are humans with
brain prosthetics if you wish - there's still human beings behind them at
this point). I do not think there is a need for a deeper policy at this
time. AI code reviews, AI security reports by various vendors have also
been useful and strengthened PostGIS in the last couple years.

I've been to communities in the past where my non-british english got me
into the "not human enough" category so I would insist that measuring
humanness of contributors is not a good path to follow. A spambot is not
welcome because of spam, not because of bot.

For other projects avoiding AI/LLM: I believe most pain is coming from
under-documenting developer workflows and standards, thus gatekeeping from
newbie people (who give up) and AIs (who don't give up, but you may not
like where they end up without guidance). I continuously make sure PostGIS
contributions are newbie-friendly (thanks Regina for showing me that way)
and it seems that also makes AI agents' involvement natural and
non-annoying.

Thanks,
Darafei.


On Tue, Jun 9, 2026 at 2:16?PM Greg Troxel <gdt at lexort.com> wrote:

> A human recently told me to make this a new thread :-)
>
> Recently qgis and gdal have discussed and adopted policy about
> LLM-generated content in mostly PRs.
>
> After "human must be in control and really understand" was agreed to in
> gdal, somewhat (in my fuzzy view) as a compromise between the "just no"
> camps and those that were somewhat more welcoming, somewhat as an
> interim, a new policy of pretty much "just no" (except for fancy
> autocomplete by those with clue) was proposed and adopted.  Basic issues
> were limited human maintainer bandwidth, humans not being happy about
> interacting with machines, and code that looks very plausible but isn't
> quite right, in a way that's very hard to identify.
>
> qgis policy:
>
>
> https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md
>
> revised gdal policy, after a brief experiment with a policy like qgis's:
>
>   https://gdal.org/en/stable/community/ai_tool_policy.html
>
>
> My own experience was in seeing hamlib (not geo) get a vibe-coded PR
> while talking about policy, and I and several others reviewed it.  Both
> code and PR text were very wordy, in a way that wasn't helpful, and in
> the end we decided the PR was off base.  But it took a lot of time, it
> was hard to determine if it was right or not, and a (trained software
> engineer) human would have made much smaller changes and explained them
> far more concisely.  This experiment left me thinking that it wasn't ok
> to ask humans to review, read, or otherwise deal with LLM output.
>
> Thus, I favor the gdal approach.  I suspect that after a few vibe-coded
> PRs, those reviewing them will prefer that too.
>
> Regardless of how the consensus ends up, postgis should state the rules
> in CONTRIBUTING, and IMHO the rules should include up-front disclosure
> of *any* LLM use in making a contribution, beyond the human contributor
> gaining understanding.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260609/b9360f60/attachment.htm>

From me at komzpa.net  Tue Jun  9 07:24:29 2026
From: me at komzpa.net (=?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?=)
Date: Tue, 9 Jun 2026 18:24:29 +0400
Subject: PSC Vote: PostGIS 3.7.0 beta1
In-Reply-To: <aib9ZRYqbyD9q81-@c19.localdomain>
References: <000401dcf204$d34a38c0$79deaa40$@pcorp.us>
 <aib9ZRYqbyD9q81-@c19.localdomain>
Message-ID: <CAC8Q8tLjCsS_OGE++ejx3gAyiWyMghsU01xQnsASgCh7Fb9r2A@mail.gmail.com>

+1 from Darafei

On Mon, Jun 8, 2026 at 9:35?PM Sandro Santilli <strk at kbt.io> wrote:

>
> +1 but I'd like to get the agentic coders file organization sorted out
> before we go final.
>

Moved them back to the doc folder, I hope it's good enough.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260609/c4574e5c/attachment.htm>

From pramsey at cleverelephant.ca  Tue Jun  9 10:03:14 2026
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Tue, 9 Jun 2026 10:03:14 -0700
Subject: Docs Format
Message-ID: <CACowWR2Fy2Jz5PUEgBpqSFfFwOhb4L0vcPAqmkgUppFPMmo6cg@mail.gmail.com>

Speaking of things that need their own thread, Darafei said:

> Another thing that may be useful to get raised: how tied are we to having docs as xml? I think gdal moved to rst and it has made it a little easier to navigate the sources of the docs on the file level.

I would say we are mostly tied to XML insofar as changing is a lot of
work, but also in that we are generating per-function pages that are
great for PostGIS SEO. Any rst/md replacement would have to be able to
generate those too.

Regina would probably also note that the strict function formatting in
docbook lets us find automatically when docs and SQL defs are out of
sync, and also generate SQL comments for the functions automatically,
and also generate categorizations of the functions.

I would say that LLMs are probably not a great motivator to change, as
I am sure they deal with the markup just fine and don't care that it
is "hard to read" and "harder to write".

I think I would like to see a migration before signing on to a big change.

P

From lnicola at dend.ro  Tue Jun  9 10:06:08 2026
From: lnicola at dend.ro (=?UTF-8?Q?Lauren=C8=9Biu_Nicola?=)
Date: Tue, 09 Jun 2026 20:06:08 +0300
Subject: Docs Format
In-Reply-To: <CACowWR2Fy2Jz5PUEgBpqSFfFwOhb4L0vcPAqmkgUppFPMmo6cg@mail.gmail.com>
References: <CACowWR2Fy2Jz5PUEgBpqSFfFwOhb4L0vcPAqmkgUppFPMmo6cg@mail.gmail.com>
Message-ID: <80fba702-de31-468c-8542-613d7f6dcba6@betaapp.fastmail.com>

LLMs love XML: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices#structure-prompts-with-xml-tags

Laurentiu

On Tue, Jun 9, 2026, at 20:03, Paul Ramsey wrote:
> Speaking of things that need their own thread, Darafei said:
>
>> Another thing that may be useful to get raised: how tied are we to having docs as xml? I think gdal moved to rst and it has made it a little easier to navigate the sources of the docs on the file level.
>
> I would say we are mostly tied to XML insofar as changing is a lot of
> work, but also in that we are generating per-function pages that are
> great for PostGIS SEO. Any rst/md replacement would have to be able to
> generate those too.
>
> Regina would probably also note that the strict function formatting in
> docbook lets us find automatically when docs and SQL defs are out of
> sync, and also generate SQL comments for the functions automatically,
> and also generate categorizations of the functions.
>
> I would say that LLMs are probably not a great motivator to change, as
> I am sure they deal with the markup just fine and don't care that it
> is "hard to read" and "harder to write".
>
> I think I would like to see a migration before signing on to a big change.
>
> P

From gdt at lexort.com  Wed Jun 10 16:57:57 2026
From: gdt at lexort.com (Greg Troxel)
Date: Wed, 10 Jun 2026 19:57:57 -0400
Subject: Should agentic skill files be elsewhere ?
In-Reply-To: <CAC8Q8tLn5a+cDfw=CmD61o5ZqKj0jtm+LWhK_faQaSnti0D3uQ@mail.gmail.com>
 ("Darafei =?utf-8?Q?=5C=22Kom=D1=8Fpa=5C=22?= Praliaskouski"'s message of
 "Tue, 9 Jun 2026 15:56:30 +0400")
References: <aicC6Xw862yao3x1@c19.localdomain>
 <BDF2EBD9-66E7-4D07-90FD-00B47600FEEC@cleverelephant.ca>
 <aifeiqTpJuNeOiYs@c19.localdomain>
 <CAC8Q8tLn5a+cDfw=CmD61o5ZqKj0jtm+LWhK_faQaSnti0D3uQ@mail.gmail.com>
Message-ID: <rmiik7qgd8a.fsf@s1.lexort.com>

"Darafei \"Kom?pa\" Praliaskouski" <me at komzpa.net> writes:

> Now, the concerns I heard:

What about that one of the files is about sql in general, and not about
postgis?

From me at komzpa.net  Wed Jun 10 19:41:14 2026
From: me at komzpa.net (=?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?=)
Date: Thu, 11 Jun 2026 06:41:14 +0400
Subject: Performance of ST_OrderingEquals
In-Reply-To: <CACowWR3LrY5MEucEwex5DZKBn_hKOJ1XDaGiO7+Etj9ZXRKVtA@mail.gmail.com>
References: <9ea6f81cb2c148dab4de47041f98e61b@strasbourg.eu>
 <CACowWR2Po9ZUa7oa7q2MHN8yEuACv7o4CFO7wzES3zrqwA6ZyQ@mail.gmail.com>
 <CACowWR3LrY5MEucEwex5DZKBn_hKOJ1XDaGiO7+Etj9ZXRKVtA@mail.gmail.com>
Message-ID: <CAC8Q8tJGWV2YZC-qXKK-qZ92L0y_rvSk5QeBnNygqsjkedkzEQ@mail.gmail.com>

Can we fix it using the same mechanics as ST_Intersects injecting the
operators into the plan? Like https://github.com/postgis/postgis/pull/875

On Thu, Jun 4, 2026 at 7:19?PM Paul Ramsey via postgis-users <
postgis-users at lists.osgeo.org> wrote:

> The problem seems to be higher up. The actual implementation of
> ST_OrderingEquals calls into gserialized_cmp quite quickly and that
> function is deliberately very very vast. I can actually make your
> query even faster by just using "where d1.geom = d2.geom" which
> directly calls into gserialized_cmp. The issue is not the function,
> but the plan. Using the = operator we get a HashJoin, using the WKB we
> get a MergeJoin, while using the ST_OrderingEquals function we get a
> NestedLoopJoin, even if we push the cost of the joining function down
> to nothing.
>
> ALTER FUNCTION ST_OrderingEquals (geometry, geometry) COST 0.00001;
>
> I'm not sure if there's any way around this, the NestedLoopJoin might
> be a consequence of the join condition being a function rather than an
> operator, it would take some digging to figure why PostgreSQL is
> choosing it.
>
> On Mon, Jun 1, 2026 at 7:55?AM MONTICOLO Julien
> <Julien.MONTICOLO at strasbourg.eu> wrote:
> >
> > Hello everyone,
> >
> >
> >
> > I recently worked on a query to check duplicates.
> >
> > I initially used ST_OrderingEquals to find exact matches.
> >
> > But with a great number of geometries, the query takes a long time.
> >
> > I changed the ST_OrderingEquals by comparison of WKB and this is a lot
> faster.
> >
> >
> >
> > Here the code to reproduce. I generate a table with 20000 points in the
> RGF93 / Lambert-93, french main CRS.
> >
> >
> >
> > SELECT version() ;  -- PostgreSQL 16.9 on x86_64-pc-linux-gnu, compiled
> by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-26), 64-bit
> >
> > SELECT postgis_version();  -- 3.4 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
> >
> >
> >
> > SELECT
> >
> >     ROW_NUMBER() OVER()::BIGINT AS id,
> >
> >     ST_POINT(
> >
> >         CEIL(100000 + RANDOM() * 1100000),
> >
> >         CEIL(6000000 + RANDOM() * 1100000),
> >
> >         2154
> >
> >     )::GEOMETRY(POINT, 2154) AS geom
> >
> > INTO TEMPORARY TABLE my_point_table
> >
> > FROM
> >
> >     GENERATE_SERIES(1, 20000)
> >
> > ;
> >
> >
> >
> > WITH pt_tab_with_dup AS (
> >
> > SELECT id, geom FROM my_point_table UNION ALL
> >
> > SELECT id * -1, geom FROM my_point_table TABLESAMPLE BERNOULLI (10)
> >
> > )
> >
> > SELECT
> >
> >     d1.id
> >
> > FROM
> >
> >     pt_tab_with_dup d1,
> >
> >     pt_tab_with_dup d2
> >
> > WHERE
> >
> >     d1.id > d2.id
> >
> >     AND ST_OrderingEquals(d1.geom, d2.geom)
> >
> > ;  -- 2 min 36 sec
> >
> >
> >
> >
> >
> > WITH pt_tab_with_dup AS (
> >
> > SELECT id, geom FROM my_point_table UNION ALL
> >
> > SELECT id * -1, geom FROM my_point_table TABLESAMPLE BERNOULLI (10)
> >
> > )
> >
> > SELECT
> >
> >     d1.id
> >
> > FROM
> >
> >     pt_tab_with_dup d1,
> >
> >     pt_tab_with_dup d2
> >
> > WHERE
> >
> >     d1.id > d2.id
> >
> >     AND ST_AsBinary(d1.geom) = ST_AsBinary(d2.geom)
> >
> > ;  -- 0.153 sec
> >
> >
> >
> >
> >
> > I think it?s correct.
> >
> > Are there any cases where it doesn?t work ? If so, why not improve the
> ST_OrderingEquals by comparing the WKB ?
> >
> >
> >
> > Kind regards,
> >
> > Julien Monticolo
> >
> >
> >
> >
> >
> > Ce message est ?tabli ? usage exclusif de son destinataire.
> > Toute utilisation ou diffusion, partielle ou totale, doit ?tre
> pr?alablement autoris?e.
> >
> > Tout message ?lectronique est susceptible d'alt?ration et son int?grit?
> ne peut ?tre assur?e.
> > L'exp?diteur d?cline toute responsabilit? au titre de ce message s'il a
> ?t? modifi? ou falsifi?.
> >
> > Si vous n'?tes pas destinataire de ce message, merci de le d?truire et
> d'avertir l'exp?diteur.
> >
> > Ville et Eurom?tropole de Strasbourg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260611/50a6d5e0/attachment.htm>

From pramsey at cleverelephant.ca  Thu Jun 11 11:07:55 2026
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Thu, 11 Jun 2026 11:07:55 -0700
Subject: Performance of ST_OrderingEquals
In-Reply-To: <CAC8Q8tJGWV2YZC-qXKK-qZ92L0y_rvSk5QeBnNygqsjkedkzEQ@mail.gmail.com>
References: <9ea6f81cb2c148dab4de47041f98e61b@strasbourg.eu>
 <CACowWR2Po9ZUa7oa7q2MHN8yEuACv7o4CFO7wzES3zrqwA6ZyQ@mail.gmail.com>
 <CACowWR3LrY5MEucEwex5DZKBn_hKOJ1XDaGiO7+Etj9ZXRKVtA@mail.gmail.com>
 <CAC8Q8tJGWV2YZC-qXKK-qZ92L0y_rvSk5QeBnNygqsjkedkzEQ@mail.gmail.com>
Message-ID: <CACowWR0dPCO6hT_gt0YShBzqY=nA6ujdCQ1sCmmbMLoZ1zvBBw@mail.gmail.com>

That seems like it would work, but then I wonder if changing
ST_OrderingEquals(A, B) to a SQL language function that just does A =
B would work just as well? PostgreSQL generally inlines SQL functions.

P.

On Wed, Jun 10, 2026 at 7:41?PM Darafei "Kom?pa" Praliaskouski
<me at komzpa.net> wrote:
>
> Can we fix it using the same mechanics as ST_Intersects injecting the operators into the plan? Like https://github.com/postgis/postgis/pull/875
>
> On Thu, Jun 4, 2026 at 7:19?PM Paul Ramsey via postgis-users <postgis-users at lists.osgeo.org> wrote:
>>
>> The problem seems to be higher up. The actual implementation of
>> ST_OrderingEquals calls into gserialized_cmp quite quickly and that
>> function is deliberately very very vast. I can actually make your
>> query even faster by just using "where d1.geom = d2.geom" which
>> directly calls into gserialized_cmp. The issue is not the function,
>> but the plan. Using the = operator we get a HashJoin, using the WKB we
>> get a MergeJoin, while using the ST_OrderingEquals function we get a
>> NestedLoopJoin, even if we push the cost of the joining function down
>> to nothing.
>>
>> ALTER FUNCTION ST_OrderingEquals (geometry, geometry) COST 0.00001;
>>
>> I'm not sure if there's any way around this, the NestedLoopJoin might
>> be a consequence of the join condition being a function rather than an
>> operator, it would take some digging to figure why PostgreSQL is
>> choosing it.
>>
>> On Mon, Jun 1, 2026 at 7:55?AM MONTICOLO Julien
>> <Julien.MONTICOLO at strasbourg.eu> wrote:
>> >
>> > Hello everyone,
>> >
>> >
>> >
>> > I recently worked on a query to check duplicates.
>> >
>> > I initially used ST_OrderingEquals to find exact matches.
>> >
>> > But with a great number of geometries, the query takes a long time.
>> >
>> > I changed the ST_OrderingEquals by comparison of WKB and this is a lot faster.
>> >
>> >
>> >
>> > Here the code to reproduce. I generate a table with 20000 points in the RGF93 / Lambert-93, french main CRS.
>> >
>> >
>> >
>> > SELECT version() ;  -- PostgreSQL 16.9 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-26), 64-bit
>> >
>> > SELECT postgis_version();  -- 3.4 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
>> >
>> >
>> >
>> > SELECT
>> >
>> >     ROW_NUMBER() OVER()::BIGINT AS id,
>> >
>> >     ST_POINT(
>> >
>> >         CEIL(100000 + RANDOM() * 1100000),
>> >
>> >         CEIL(6000000 + RANDOM() * 1100000),
>> >
>> >         2154
>> >
>> >     )::GEOMETRY(POINT, 2154) AS geom
>> >
>> > INTO TEMPORARY TABLE my_point_table
>> >
>> > FROM
>> >
>> >     GENERATE_SERIES(1, 20000)
>> >
>> > ;
>> >
>> >
>> >
>> > WITH pt_tab_with_dup AS (
>> >
>> > SELECT id, geom FROM my_point_table UNION ALL
>> >
>> > SELECT id * -1, geom FROM my_point_table TABLESAMPLE BERNOULLI (10)
>> >
>> > )
>> >
>> > SELECT
>> >
>> >     d1.id
>> >
>> > FROM
>> >
>> >     pt_tab_with_dup d1,
>> >
>> >     pt_tab_with_dup d2
>> >
>> > WHERE
>> >
>> >     d1.id > d2.id
>> >
>> >     AND ST_OrderingEquals(d1.geom, d2.geom)
>> >
>> > ;  -- 2 min 36 sec
>> >
>> >
>> >
>> >
>> >
>> > WITH pt_tab_with_dup AS (
>> >
>> > SELECT id, geom FROM my_point_table UNION ALL
>> >
>> > SELECT id * -1, geom FROM my_point_table TABLESAMPLE BERNOULLI (10)
>> >
>> > )
>> >
>> > SELECT
>> >
>> >     d1.id
>> >
>> > FROM
>> >
>> >     pt_tab_with_dup d1,
>> >
>> >     pt_tab_with_dup d2
>> >
>> > WHERE
>> >
>> >     d1.id > d2.id
>> >
>> >     AND ST_AsBinary(d1.geom) = ST_AsBinary(d2.geom)
>> >
>> > ;  -- 0.153 sec
>> >
>> >
>> >
>> >
>> >
>> > I think it?s correct.
>> >
>> > Are there any cases where it doesn?t work ? If so, why not improve the ST_OrderingEquals by comparing the WKB ?
>> >
>> >
>> >
>> > Kind regards,
>> >
>> > Julien Monticolo
>> >
>> >
>> >
>> >
>> >
>> > Ce message est ?tabli ? usage exclusif de son destinataire.
>> > Toute utilisation ou diffusion, partielle ou totale, doit ?tre pr?alablement autoris?e.
>> >
>> > Tout message ?lectronique est susceptible d'alt?ration et son int?grit? ne peut ?tre assur?e.
>> > L'exp?diteur d?cline toute responsabilit? au titre de ce message s'il a ?t? modifi? ou falsifi?.
>> >
>> > Si vous n'?tes pas destinataire de ce message, merci de le d?truire et d'avertir l'exp?diteur.
>> >
>> > Ville et Eurom?tropole de Strasbourg

From lr at pcorp.us  Thu Jun 11 12:41:53 2026
From: lr at pcorp.us (Regina Obe)
Date: Thu, 11 Jun 2026 15:41:53 -0400
Subject: Meet before releasing PostGIS 3.7.0beta1
Message-ID: <000001dcf9da$5be47d80$13ad7880$@pcorp.us>

As I mentioned on irc/matrix, I'd like to have a PostGIS development meeting
before I call PostGIS 3.7.0beta1 to make sure we have no loose ends and no
major things that require SQL / API changes that people are looking to have
in upcoming PostGIS 3.7.0.  Note things under the hood we can change a lot
before release, just want to make sure the SQL API stuff signatures don't
change (no additions or subtractions).

I'm thinking sometime next week perhaps 
 June 16th 4 PM UTC

https://www.timeanddate.com/worldclock/meetingtime.html?iso=20260616&p1=43&p
2=256&p3=215&p4=371

Or June 20th 6 AM UTC
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2026&month=6
&day=20&hour=6&min=0&sec=0&p1=43&p2=256&p3=215&p4=371

As always the meeting is open to everyone, not just PostGIS devs and will be
here:

https://meet.osgeo.org/postgis


Does anyone have issue with either time and if you have a preference for one
over the other let me know.

Thanks,
Regina




From pramsey at cleverelephant.ca  Thu Jun 11 13:57:43 2026
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Thu, 11 Jun 2026 13:57:43 -0700
Subject: Meet before releasing PostGIS 3.7.0beta1
In-Reply-To: <000001dcf9da$5be47d80$13ad7880$@pcorp.us>
References: <000001dcf9da$5be47d80$13ad7880$@pcorp.us>
Message-ID: <CACowWR0PU4Kfm-PUY_ms6LL5Q0CRBpH+fzfFbttse1tgA+n7_g@mail.gmail.com>

On Thu, Jun 11, 2026 at 12:41?PM Regina Obe <lr at pcorp.us> wrote:
>
> As I mentioned on irc/matrix, I'd like to have a PostGIS development meeting
> before I call PostGIS 3.7.0beta1 to make sure we have no loose ends and no

> I'm thinking sometime next week perhaps
>  June 16th 4 PM UTC
> https://www.timeanddate.com/worldclock/meetingtime.html?iso=20260616&p1=43&p
> 2=256&p3=215&p4=371

Can do this.

>
> Or June 20th 6 AM UTC
> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2026&month=6
> &day=20&hour=6&min=0&sec=0&p1=43&p2=256&p3=215&p4=371
>
> As always the meeting is open to everyone, not just PostGIS devs and will be
> here:
>
> https://meet.osgeo.org/postgis
>
>
> Does anyone have issue with either time and if you have a preference for one
> over the other let me know.
>
> Thanks,
> Regina
>
>
>

From strk at kbt.io  Fri Jun 12 10:53:47 2026
From: strk at kbt.io (Sandro Santilli)
Date: Fri, 12 Jun 2026 19:53:47 +0200
Subject: Meet before releasing PostGIS 3.7.0beta1
In-Reply-To: <CACowWR0PU4Kfm-PUY_ms6LL5Q0CRBpH+fzfFbttse1tgA+n7_g@mail.gmail.com>
References: <000001dcf9da$5be47d80$13ad7880$@pcorp.us>
 <CACowWR0PU4Kfm-PUY_ms6LL5Q0CRBpH+fzfFbttse1tgA+n7_g@mail.gmail.com>
Message-ID: <aixHqwhj5n6Cjxal@c19.localdomain>

On Thu, Jun 11, 2026 at 01:57:43PM -0700, Paul Ramsey wrote:
> On Thu, Jun 11, 2026 at 12:41?PM Regina Obe <lr at pcorp.us> wrote:
> >
> > As I mentioned on irc/matrix, I'd like to have a PostGIS development meeting
> > before I call PostGIS 3.7.0beta1 to make sure we have no loose ends and no
> 
> > I'm thinking sometime next week perhaps
> >  June 16th 4 PM UTC
> > https://www.timeanddate.com/worldclock/meetingtime.html?iso=20260616&p1=43&p
> > 2=256&p3=215&p4=371
> 
> Can do this.

Works for me too, 17:00 Europe/Rome works for you guys ?
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2026&month=6&day=16&hour=15&min=0&sec=0&p1=43&p2=256&p3=215&p4=371

--strk;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260612/f95f1c11/attachment.sig>

From strk at kbt.io  Fri Jun 12 11:17:02 2026
From: strk at kbt.io (Sandro Santilli)
Date: Fri, 12 Jun 2026 20:17:02 +0200
Subject: LLM policy
In-Reply-To: <CAC8Q8t+bdsivBS-=5v25s-GC4g7oTZfKhXT-Bqmb_yQkGYB2iw@mail.gmail.com>
References: <rmiv7bsj9x5.fsf@s1.lexort.com>
 <CAC8Q8t+bdsivBS-=5v25s-GC4g7oTZfKhXT-Bqmb_yQkGYB2iw@mail.gmail.com>
Message-ID: <aixNHn1P8KClO4gy@c19.localdomain>

On Tue, Jun 09, 2026 at 05:10:51PM +0400, Darafei "Kom?pa" Praliaskouski wrote:

> I believe AIs are covered by existing diversity statement of code of conduct:
> https://postgis.net/community/conduct/#diversity-statement

I agree on not defining a policy about which tools you can use to
contribute to PostGIS.

We need to be always careful about what we merge, and if it's too
difficult to review a contribution, we should not feel pressured to
accept it.

Shall communication become too verbose we'll see how to approach that
problem, maybe we're not affected because there aren't many Coding Agents
capable of filing Trac tickets ;)

DISCLAIMER: I've started my AI/LLM research relatively recently, and
            the view I expressed in my blog from Dec 2025 still holds
            https://strk.kbt.io/articles/2025-12-01-ai.html

--strk;


  Libre GIS consultant/developer ?
  https://strk.kbt.io/services.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260612/229ff6f8/attachment.sig>

From strk at kbt.io  Fri Jun 12 11:20:04 2026
From: strk at kbt.io (Sandro Santilli)
Date: Fri, 12 Jun 2026 20:20:04 +0200
Subject: Docs Format
In-Reply-To: <CACowWR2Fy2Jz5PUEgBpqSFfFwOhb4L0vcPAqmkgUppFPMmo6cg@mail.gmail.com>
References: <CACowWR2Fy2Jz5PUEgBpqSFfFwOhb4L0vcPAqmkgUppFPMmo6cg@mail.gmail.com>
Message-ID: <aixN1Mp6EGaI5F4h@c19.localdomain>

On Tue, Jun 09, 2026 at 10:03:14AM -0700, Paul Ramsey wrote:

> I would say that LLMs are probably not a great motivator to change, as
> I am sure they deal with the markup just fine and don't care that it
> is "hard to read" and "harder to write".

I'd love to see a "write Docbook" SKILL file for that, btw.

But even better some good old shell or perl script to stub the sections
of a new function so we don't need GPUs to release the XML pain.

> I think I would like to see a migration before signing on to a big change.

What do you mean by "migration" ?

--strk; 

  Libre GIS consultant/developer ?
  https://strk.kbt.io/services.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260612/ae3818a3/attachment.sig>

From strk at kbt.io  Fri Jun 12 11:30:10 2026
From: strk at kbt.io (Sandro Santilli)
Date: Fri, 12 Jun 2026 20:30:10 +0200
Subject: PSC Vote: PostGIS 3.7.0 beta1
In-Reply-To: <CAC8Q8tLjCsS_OGE++ejx3gAyiWyMghsU01xQnsASgCh7Fb9r2A@mail.gmail.com>
References: <000401dcf204$d34a38c0$79deaa40$@pcorp.us>
 <aib9ZRYqbyD9q81-@c19.localdomain>
 <CAC8Q8tLjCsS_OGE++ejx3gAyiWyMghsU01xQnsASgCh7Fb9r2A@mail.gmail.com>
Message-ID: <aixQMmQbgz643jtg@c19.localdomain>

On Tue, Jun 09, 2026 at 06:24:29PM +0400, Darafei "Kom?pa" Praliaskouski wrote:
> 
> Moved them back to the doc folder, I hope it's good enough.

Works for me, thank you Darafei.
I've added a README file in there to guide humans.

--strk; 

  Libre GIS consultant/developer ?
  https://strk.kbt.io/services.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260612/237de981/attachment.sig>

From pramsey at cleverelephant.ca  Fri Jun 12 11:58:55 2026
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Fri, 12 Jun 2026 11:58:55 -0700
Subject: Docs Format
In-Reply-To: <aixN1Mp6EGaI5F4h@c19.localdomain>
References: <CACowWR2Fy2Jz5PUEgBpqSFfFwOhb4L0vcPAqmkgUppFPMmo6cg@mail.gmail.com>
 <aixN1Mp6EGaI5F4h@c19.localdomain>
Message-ID: <17B755E2-4DE2-4A4E-9951-8863EA17E385@cleverelephant.ca>



> On Jun 12, 2026, at 11:20?AM, Sandro Santilli <strk at kbt.io> wrote:
> But even better some good old shell or perl script to stub the sections
> of a new function so we don't need GPUs to release the XML pain.
> 
>> I think I would like to see a migration before signing on to a big change.
> 
> What do you mean by ?migration?

I mean a conversion of docbook to md or rst would be proceeded by said conversion a ?best effort? PoC

P


From pramsey at cleverelephant.ca  Fri Jun 12 11:59:46 2026
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Fri, 12 Jun 2026 11:59:46 -0700
Subject: Meet before releasing PostGIS 3.7.0beta1
In-Reply-To: <aixHqwhj5n6Cjxal@c19.localdomain>
References: <000001dcf9da$5be47d80$13ad7880$@pcorp.us>
 <CACowWR0PU4Kfm-PUY_ms6LL5Q0CRBpH+fzfFbttse1tgA+n7_g@mail.gmail.com>
 <aixHqwhj5n6Cjxal@c19.localdomain>
Message-ID: <6FFD3A1B-6379-48EE-AB02-5C5A220FB98B@cleverelephant.ca>



> On Jun 12, 2026, at 10:53?AM, Sandro Santilli <strk at kbt.io> wrote:
> 
> On Thu, Jun 11, 2026 at 01:57:43PM -0700, Paul Ramsey wrote:
>> On Thu, Jun 11, 2026 at 12:41?PM Regina Obe <lr at pcorp.us> wrote:
>>> 
>>> As I mentioned on irc/matrix, I'd like to have a PostGIS development meeting
>>> before I call PostGIS 3.7.0beta1 to make sure we have no loose ends and no
>> 
>>> I'm thinking sometime next week perhaps
>>> June 16th 4 PM UTC
>>> https://www.timeanddate.com/worldclock/meetingtime.html?iso=20260616&p1=43&p
>>> 2=256&p3=215&p4=371
>> 
>> Can do this.
> 
> Works for me too, 17:00 Europe/Rome works for you guys ?
> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2026&month=6&day=16&hour=15&min=0&sec=0&p1=43&p2=256&p3=215&p4=371
> \

Yes, can do that one



> --strk;


From strk at kbt.io  Fri Jun 12 22:24:42 2026
From: strk at kbt.io (Sandro Santilli)
Date: Sat, 13 Jun 2026 07:24:42 +0200
Subject: Docs Format
In-Reply-To: <17B755E2-4DE2-4A4E-9951-8863EA17E385@cleverelephant.ca>
References: <CACowWR2Fy2Jz5PUEgBpqSFfFwOhb4L0vcPAqmkgUppFPMmo6cg@mail.gmail.com>
 <aixN1Mp6EGaI5F4h@c19.localdomain>
 <17B755E2-4DE2-4A4E-9951-8863EA17E385@cleverelephant.ca>
Message-ID: <aizpmhzi1wXe5vqf@c19.localdomain>

On Fri, Jun 12, 2026 at 11:58:55AM -0700, Paul Ramsey wrote:
> 
> 
> > On Jun 12, 2026, at 11:20?AM, Sandro Santilli <strk at kbt.io> wrote:
> > But even better some good old shell or perl script to stub the sections
> > of a new function so we don't need GPUs to release the XML pain.
> > 
> >> I think I would like to see a migration before signing on to a big change.
> > 
> > What do you mean by ?migration?
> 
> I mean a conversion of docbook to md or rst would be proceeded by said conversion a ?best effort? PoC

I personally find the Docbook way better in terms of structure.

Formats like md and rst were meant to make human-readable files a bit more machine-readable
while we want efficient machine readable structure.

Btw, today common Markdown usage badly broke the initial intention,
as often find it hard to read an .md file with just a pager, with all
those oververbose hrefs and inline images and what not...

--strk;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260613/3864c825/attachment.sig>

From gdt at lexort.com  Sat Jun 13 05:50:10 2026
From: gdt at lexort.com (Greg Troxel)
Date: Sat, 13 Jun 2026 08:50:10 -0400
Subject: LLM policy
In-Reply-To: <CAC8Q8t+bdsivBS-=5v25s-GC4g7oTZfKhXT-Bqmb_yQkGYB2iw@mail.gmail.com>
 ("Darafei =?utf-8?Q?=5C=22Kom=D1=8Fpa=5C=22?= Praliaskouski"'s message of
 "Tue, 9 Jun 2026 17:10:51 +0400")
References: <rmiv7bsj9x5.fsf@s1.lexort.com>
 <CAC8Q8t+bdsivBS-=5v25s-GC4g7oTZfKhXT-Bqmb_yQkGYB2iw@mail.gmail.com>
Message-ID: <rmibjdea9kt.fsf@s1.lexort.com>

"Darafei \"Kom?pa\" Praliaskouski" <me at komzpa.net> writes:

> I believe AIs are covered by existing diversity statement of code of
> conduct:
>
> https://postgis.net/community/conduct/#diversity-statement
>> PostGIS welcomes and encourages participation by everyone. We are
> committed to being a community that everyone feels good about joining, and
> we will always work to treat everyone well. No matter how you identify
> yourself or how others perceive you: we welcome you.

I think that is a completely unreasonable interpretation.  It has, I
think, been obvious to essentialy everyone that these sorts of
diversity/courtesy concerns about about individual humans.  There's been
no discussion, and no consensus about expanding that.

Claiming an interpretation that computer programs have rights under a
code of conduct is more or less starting from a position that programs
have the same rights as people.

> I've been to communities in the past where my non-british english got me
> into the "not human enough" category so I would insist that measuring
> humanness of contributors is not a good path to follow.

That's another unfair argument.  I'm sorry you were mistreated, but
jumping from that to "mistreatment of non-human entities is not ok" is
an unsupportable leap.

> A spambot is not welcome because of spam, not because of bot.

I disagree.  Certainly spam is unwelcome, but in a space intended for
human interaction, it is fair to object to the presence of bots even if
they are not spamming.


From gdt at lexort.com  Sat Jun 13 05:54:48 2026
From: gdt at lexort.com (Greg Troxel)
Date: Sat, 13 Jun 2026 08:54:48 -0400
Subject: LLM policy
In-Reply-To: <aixNHn1P8KClO4gy@c19.localdomain> (Sandro Santilli's message of
 "Fri, 12 Jun 2026 20:17:02 +0200")
References: <rmiv7bsj9x5.fsf@s1.lexort.com>
 <CAC8Q8t+bdsivBS-=5v25s-GC4g7oTZfKhXT-Bqmb_yQkGYB2iw@mail.gmail.com>
 <aixNHn1P8KClO4gy@c19.localdomain>
Message-ID: <rmi7bo2a9d3.fsf@s1.lexort.com>

Sandro Santilli <strk at kbt.io> writes:

> On Tue, Jun 09, 2026 at 05:10:51PM +0400, Darafei "Kom?pa" Praliaskouski wrote:
>
>> I believe AIs are covered by existing diversity statement of code of conduct:
>> https://postgis.net/community/conduct/#diversity-statement
>
> I agree on not defining a policy about which tools you can use to
> contribute to PostGIS.

It's not really about "tools you can use", but about input without
proper licensing (models trained on stolen code), and about overly
verbose input that is particularly hard to review because of an
established pattern of subtle errors while seeming plausible.

> We need to be always careful about what we merge, and if it's too
> difficult to review a contribution, we should not feel pressured to
> accept it.

Under that, the response to most LLM contributions should be to reject
them as too verbose, unless they are as tightly written as accepted
human-authored contributions.  And, to reject contributions that have a
hint of not being understand by the human submitter as well as one that
was constructed without LLM.  This is not quite a ban, but in practice
it's pretty close.

> Shall communication become too verbose we'll see how to approach that
> problem, maybe we're not affected because there aren't many Coding Agents
> capable of filing Trac tickets ;)

The problematic merge request I saw was filed by a human but the code
changes were generated by an LLM.


I suggest looking over the gdal-dev list and Even's comments after
trying to deal with LLM inputs.


But indeed, good humor about Trac.

From lr at pcorp.us  Sat Jun 13 12:10:38 2026
From: lr at pcorp.us (Regina Obe)
Date: Sat, 13 Jun 2026 15:10:38 -0400
Subject: LLM policy
In-Reply-To: <rmibjdea9kt.fsf@s1.lexort.com>
References: <rmiv7bsj9x5.fsf@s1.lexort.com>
 <CAC8Q8t+bdsivBS-=5v25s-GC4g7oTZfKhXT-Bqmb_yQkGYB2iw@mail.gmail.com>
 <rmibjdea9kt.fsf@s1.lexort.com>
Message-ID: <000001dcfb68$52d71470$f8853d50$@pcorp.us>

> "Darafei \"Kom?pa\" Praliaskouski" <me at komzpa.net> writes:
> 
> > I believe AIs are covered by existing diversity statement of code of
> > conduct:
> >
> > https://postgis.net/community/conduct/#diversity-statement
> >> PostGIS welcomes and encourages participation by everyone. We are
> > committed to being a community that everyone feels good about joining,
> > and we will always work to treat everyone well. No matter how you
> > identify yourself or how others perceive you: we welcome you.
> 
> I think that is a completely unreasonable interpretation.  It has, I think, been
> obvious to essentialy everyone that these sorts of diversity/courtesy concerns
> about about individual humans.  There's been no discussion, and no consensus
> about expanding that.
> 

Liking a lot of computers more than people, I'll tend to disagree about your comment
here that everyone only applies to humans.  I have always thought about it as extending beyond that.

In my mind if a AI / bot whatever plays well in a community,  is helpful, then it deserves the same considerations as we grant to others.
I should also say some people identify as computers ?

Remember way back when women who programmed were called "computers" cause they computed.

Thanks,
Regina






From gdt at lexort.com  Sat Jun 13 12:11:39 2026
From: gdt at lexort.com (Greg Troxel)
Date: Sat, 13 Jun 2026 15:11:39 -0400
Subject: LLM policy
In-Reply-To: <000001dcfb68$52d71470$f8853d50$@pcorp.us> (Regina Obe's message
 of "Sat, 13 Jun 2026 15:10:38 -0400")
References: <rmiv7bsj9x5.fsf@s1.lexort.com>
 <CAC8Q8t+bdsivBS-=5v25s-GC4g7oTZfKhXT-Bqmb_yQkGYB2iw@mail.gmail.com>
 <rmibjdea9kt.fsf@s1.lexort.com>
 <000001dcfb68$52d71470$f8853d50$@pcorp.us>
Message-ID: <rmiecia8dck.fsf@s1.lexort.com>

Wow.  I feel unwelcome in this community!

From gdt at lexort.com  Sat Jun 13 12:18:28 2026
From: gdt at lexort.com (Greg Troxel)
Date: Sat, 13 Jun 2026 15:18:28 -0400
Subject: LLM policy
In-Reply-To: <rmiecia8dck.fsf@s1.lexort.com> (Greg Troxel's message of "Sat,
 13 Jun 2026 15:11:39 -0400")
References: <rmiv7bsj9x5.fsf@s1.lexort.com>
 <CAC8Q8t+bdsivBS-=5v25s-GC4g7oTZfKhXT-Bqmb_yQkGYB2iw@mail.gmail.com>
 <rmibjdea9kt.fsf@s1.lexort.com>
 <000001dcfb68$52d71470$f8853d50$@pcorp.us>
 <rmiecia8dck.fsf@s1.lexort.com>
Message-ID: <rmi4ij68d17.fsf@s1.lexort.com>

Greg Troxel <gdt at lexort.com> writes:

> Wow.  I feel unwelcome in this community!

What I mean is I feel I've just been told that I'm violating commmunity
standards by being unwilling to grant computers the same rights as
people.

The overall situation of discusssing AI in the context of a code of
conduct is uncomfortable,

From lr at pcorp.us  Sat Jun 13 12:37:58 2026
From: lr at pcorp.us (Regina Obe)
Date: Sat, 13 Jun 2026 15:37:58 -0400
Subject: LLM policy
In-Reply-To: <rmi4ij68d17.fsf@s1.lexort.com>
References: <rmiv7bsj9x5.fsf@s1.lexort.com>	<CAC8Q8t+bdsivBS-=5v25s-GC4g7oTZfKhXT-Bqmb_yQkGYB2iw@mail.gmail.com>	<rmibjdea9kt.fsf@s1.lexort.com>	<000001dcfb68$52d71470$f8853d50$@pcorp.us>	<rmiecia8dck.fsf@s1.lexort.com>
 <rmi4ij68d17.fsf@s1.lexort.com>
Message-ID: <000701dcfb6c$23e60870$6bb21950$@pcorp.us>

> Greg Troxel <gdt at lexort.com> writes:
> 
> > Wow.  I feel unwelcome in this community!
> 
> What I mean is I feel I've just been told that I'm violating commmunity
> standards by being unwilling to grant computers the same rights as people.
> 

I wouldn't say violating.  I'd just say a difference of opinion here.
You assume everyone agrees with you in this, Darafei and I are telling you
we don't.

We all have rights to our opinions and if our opinions disagree someone is
bound to feel uncomfortable.
I'm sorry we made you feel uncomfortable.

> The overall situation of discusssing AI in the context of a code of
conduct is
> uncomfortable,

Code of conduct is always an uncomfortable thing to discuss cause it
highlights our prejudices and how we don't all think alike.
The way I see it, the issue people have with AI is the following:

1) AI is disruptive when it creates garbage someone needs to review
2) AI might provide pull requests that violate copyright

There are probably some others but that is my main issue with any AI when it
does that. 
It is violating someone else's needs / etc for very concrete reasons more
than it is adding value to others.

When you start micromanaging what should be considered "everyone", you start
getting into 
Dangerous territory such as "Your guide dog is not welcome" even though you
need it to guide you around, therefore "you are not welcome because you need
a guide dog"

Judge the acts, not the thing.  

We have a code of conduct because we try to make sure as best we can that
one's needs don't violate another's.
Sometimes those are in conflict mostly because of someone's internal
perspective about things and unfortunately there is nothing that
can be done about that. We have to choose sides.

Greg I hope you realize we do value your opinions very much even when we
don't agree with them.  So don't let a difference of opinion make you feel
unwelcome.

Thanks,
Regina



From lr at pcorp.us  Sat Jun 13 12:46:32 2026
From: lr at pcorp.us (Regina Obe)
Date: Sat, 13 Jun 2026 15:46:32 -0400
Subject: Docs Format
In-Reply-To: <17B755E2-4DE2-4A4E-9951-8863EA17E385@cleverelephant.ca>
References: <CACowWR2Fy2Jz5PUEgBpqSFfFwOhb4L0vcPAqmkgUppFPMmo6cg@mail.gmail.com>
 <aixN1Mp6EGaI5F4h@c19.localdomain>
 <17B755E2-4DE2-4A4E-9951-8863EA17E385@cleverelephant.ca>
Message-ID: <000801dcfb6d$56df3cf0$049db6d0$@pcorp.us>

> > On Jun 12, 2026, at 11:20?AM, Sandro Santilli <strk at kbt.io> wrote:
> > But even better some good old shell or perl script to stub the
> > sections of a new function so we don't need GPUs to release the XML pain.
> >
> >> I think I would like to see a migration before signing on to a big change.
> >
> > What do you mean by ?migration?
> 
> I mean a conversion of docbook to md or rst would be proceeded by said
> conversion a ?best effort? PoC
> 
> P

I think people probably know how I feel about docbook vs. md as Paul pointed out.

https://lists.osgeo.org/pipermail/postgis-devel/2026-June/030777.html

I love md for readability, but I love docbook more for its exactness.
I think it will always be easier to morph docbook into md or any other human niceable format and not lose any meaning than it would be the other way around.
To go from a human niceable format to docbook I see as a somewhat ambiguous thing.

I do see Darafei's point about the docs in source being hard to navigate.  That seems to be the most fundamental problem and would like it if we can solve in other ways.
Like I mentioned in matrix/irc, perhaps putting a link on the viewable docs to the xml file it belongs.  

To Sandro's point, it would make more sense for us to allow a human to write in whatever format they want and have it at least
partially translate it for them if they are struggling.

As Lauren?iu mentioned https://lists.osgeo.org/pipermail/postgis-devel/2026-June/030778.html

I find it hard to believe that AI has any issue with docbook and I think quite the contrary.  So doing this cause AI has an easier time seems like a very bad reason.

Thanks,
Regna


From lr at pcorp.us  Sat Jun 13 12:50:03 2026
From: lr at pcorp.us (Regina Obe)
Date: Sat, 13 Jun 2026 15:50:03 -0400
Subject: Meet before releasing PostGIS 3.7.0beta1
In-Reply-To: <aixHqwhj5n6Cjxal@c19.localdomain>
References: <000001dcf9da$5be47d80$13ad7880$@pcorp.us>
 <CACowWR0PU4Kfm-PUY_ms6LL5Q0CRBpH+fzfFbttse1tgA+n7_g@mail.gmail.com>
 <aixHqwhj5n6Cjxal@c19.localdomain>
Message-ID: <000f01dcfb6d$d48ba1c0$7da2e540$@pcorp.us>

> On Thu, Jun 11, 2026 at 01:57:43PM -0700, Paul Ramsey wrote:
> > On Thu, Jun 11, 2026 at 12:41?PM Regina Obe <lr at pcorp.us> wrote:
> > >
> > > As I mentioned on irc/matrix, I'd like to have a PostGIS development
> > > meeting before I call PostGIS 3.7.0beta1 to make sure we have no
> > > loose ends and no
> >
> > > I'm thinking sometime next week perhaps  June 16th 4 PM UTC
> > >
> https://www.timeanddate.com/worldclock/meetingtime.html?iso=20260616
> > > &p1=43&p
> > > 2=256&p3=215&p4=371
> >
> > Can do this.
> 
> Works for me too, 17:00 Europe/Rome works for you guys ?
> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2026&
> month=6&day=16&hour=15&min=0&sec=0&p1=43&p2=256&p3=215&p4=37
> 1
> 
> --strk;

I'm going to assume anyone who hasn't responded either can't come or this time works:

June 16th 4 PM UTC

https://www.timeanddate.com/worldclock/meetingtime.html?iso=20260616&p1=43&p2=256&p3=215&p4=371

So see you all there at June 16th 4 PM UTC  https://meet.osgeo.org/postgis

Thanks,
Regina



From gdt at lexort.com  Sat Jun 13 12:57:45 2026
From: gdt at lexort.com (Greg Troxel)
Date: Sat, 13 Jun 2026 15:57:45 -0400
Subject: LLM policy
In-Reply-To: <000701dcfb6c$23e60870$6bb21950$@pcorp.us> (Regina Obe's message
 of "Sat, 13 Jun 2026 15:37:58 -0400")
References: <rmiv7bsj9x5.fsf@s1.lexort.com>
 <CAC8Q8t+bdsivBS-=5v25s-GC4g7oTZfKhXT-Bqmb_yQkGYB2iw@mail.gmail.com>
 <rmibjdea9kt.fsf@s1.lexort.com>
 <000001dcfb68$52d71470$f8853d50$@pcorp.us>
 <rmiecia8dck.fsf@s1.lexort.com> <rmi4ij68d17.fsf@s1.lexort.com>
 <000701dcfb6c$23e60870$6bb21950$@pcorp.us>
Message-ID: <rmise6q6wna.fsf@s1.lexort.com>

"Regina Obe" <lr at pcorp.us> writes:

>> Greg Troxel <gdt at lexort.com> writes:
>> 
>> > Wow.  I feel unwelcome in this community!
>> 
>> What I mean is I feel I've just been told that I'm violating commmunity
>> standards by being unwilling to grant computers the same rights as people.
>> 
>
> I wouldn't say violating.  I'd just say a difference of opinion here.
> You assume everyone agrees with you in this, Darafei and I are telling you
> we don't.
>
> We all have rights to our opinions and if our opinions disagree someone is
> bound to feel uncomfortable.
> I'm sorry we made you feel uncomfortable.

Thanks.

I'm fine with differences of opinion as in "we should be ok with LLM
inputs" vs "we should not be ok with LLM inputs".

What is not comfortable is "I assert that the code of conduct says that
we must welcome LLMs as community members."

>> The overall situation of discusssing AI in the context of a code of
> conduct is
>> uncomfortable,
>
> Code of conduct is always an uncomfortable thing to discuss cause it
> highlights our prejudices and how we don't all think alike.

Discussing our preconceptions is yes, and I've always seen the higher
level issue is that we should  only argue about ideas and not object to
people because of some aspect of their being.

What's uncomfortable about "code of conduct" vs a broad expectation of
behavior is that it seems to end up (not here) turning into a lever to
censor people, well beyond what it should have intended.

> The way I see it, the issue people have with AI is the following:
>
> 1) AI is disruptive when it creates garbage someone needs to review
> 2) AI might provide pull requests that violate copyright
>
> There are probably some others but that is my main issue with any AI when it
> does that. 
> It is violating someone else's needs / etc for very concrete reasons more
> than it is adding value to others.

Yes, and

3) AI systems are disruptive by how they scrape to gather training data,
and many people have had to spend time building and configuring systems
to avoid this.

Maybe not every AI system, but I have seen no system of the sort that
people use with a documented/transparent explanation of how they do not
engage in abusive scraping and how they do not use content for training
without permission and respecting licenses.

> When you start micromanaging what should be considered "everyone", you start
> getting into 
> Dangerous territory such as "Your guide dog is not welcome" even though you
> need it to guide you around, therefore "you are not welcome because you need
> a guide dog"

I really cannot see this as reasonable.  Everyone is all humans, and
extending it to LLMs seems novel and at best highly controversial.

The issue of assistance animals is more or less settled in law, but
there is excluding people who need them on one hand, and excluding
people with allergies on the other.  It's not 100% straightforward, and
we don't discuss it really because in the US it's settled law.

> Judge the acts, not the thing.  

That could apply to UAS, saying there should be no rules about
beyond-LOS drones as long as they fly ok.   It's a step into a vast set
of unconsidered consequences.

Interestingly, I have never before encountered the idea that it is
improper to exclude LLM content because of "not treating LLMS like
people and it's discriminatory", despite similar discussions in many
other projects.  Just a data point about previous observations.

> We have a code of conduct because we try to make sure as best we can that
> one's needs don't violate another's.
> Sometimes those are in conflict mostly because of someone's internal
> perspective about things and unfortunately there is nothing that
> can be done about that. We have to choose sides.

This is part of where it gets problematic, with the modern theory of
harm from ideas (again, not showing up here).

> Greg I hope you realize we do value your opinions very much even when we
> don't agree with them.  So don't let a difference of opinion make you feel
> unwelcome.

Thanks.  As long as it's a difference of opinion and not that people
that object to LLM content are deemed to be CoC offenders, then it's
fine.

(Separately, I might choose to disengage from a project that's ok with
LLMs, just as those that want to use them for everything might disengage
from projects where they aren't welcome, but that's not the same thing.)


From lr at pcorp.us  Sat Jun 13 14:46:26 2026
From: lr at pcorp.us (Regina Obe)
Date: Sat, 13 Jun 2026 17:46:26 -0400
Subject: LLM policy
In-Reply-To: <01ef11a6-209c-4ba2-8e99-4c8b3c9731f7@spatialys.com>
References: <rmiv7bsj9x5.fsf@s1.lexort.com>
 <CAC8Q8t+bdsivBS-=5v25s-GC4g7oTZfKhXT-Bqmb_yQkGYB2iw@mail.gmail.com>
 <rmibjdea9kt.fsf@s1.lexort.com> <000001dcfb68$52d71470$f8853d50$@pcorp.us>
 <rmiecia8dck.fsf@s1.lexort.com> <rmi4ij68d17.fsf@s1.lexort.com>
 <000701dcfb6c$23e60870$6bb21950$@pcorp.us> <rmise6q6wna.fsf@s1.lexort.com>
 <01ef11a6-209c-4ba2-8e99-4c8b3c9731f7@spatialys.com>
Message-ID: <000201dcfb7e$170c85e0$452591a0$@pcorp.us>

> > I really cannot see this as reasonable.  Everyone is all humans, and
> > extending it to LLMs seems novel and at best highly controversial.
> 
> Strong +1 here. I'm very shocked by statements that LLMs could qualify as
> "someone". Someone obviously involves a biological entity originating from
> human cells. If we start to acknowledge rights to bots, then humanity is in
> high danger. Especially since ethical AI doesn't exist (there might be lab
> experiments around that, but in practice that's not the one people use when
> they use commercial models). So you're currently dealing with things explicitly
> designed to make human users addict.
> There are numerous testimonies of events where "agents" start leaving the
> framework in which they were initially thought to be restricted and play
> according to their own "intents", and given the high dependence of our
> societies to computer networks, this is deeply concerning.
> 
> Even
> 
> --
> http://www.spatialys.com
> My software is free, but my time generally not.

We are 99% not human cells, we have way more bacteria in our body than human cells.
Our emotions everything boils down to what other things in our body are causing us pain or giving us pleasure.

Again I say we can come to the same conclusion by not debating what is everyone.

If a human kills you do you consider them more welcome than AI? 
You don't need AI to be unethical so the argument seems silly  -- just dump anthrax in peoples water.  Just throw an A-bomb on a continent. Put guards in to prevent the action not the thing or everyone doing it.

I still stand by "you judge the actions not the thing doing it, if you have concluded all things of that class are bad, then fine, block all those".
If something causes people to be addicts, it's bad period - that could be a drug dealer or AI.  I see no point in isolating AI out as if it were the only thing capable of evil in this world and simply because we deem it not human and therefore not worthy of respect.

My pace-maker could be co-opted, should I be deeply concerned, Yes, should I ban the pace-maker from my body? No.










From even.rouault at spatialys.com  Sat Jun 13 14:01:42 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Sat, 13 Jun 2026 23:01:42 +0200
Subject: LLM policy
In-Reply-To: <rmise6q6wna.fsf@s1.lexort.com>
References: <rmiv7bsj9x5.fsf@s1.lexort.com>
 <CAC8Q8t+bdsivBS-=5v25s-GC4g7oTZfKhXT-Bqmb_yQkGYB2iw@mail.gmail.com>
 <rmibjdea9kt.fsf@s1.lexort.com> <000001dcfb68$52d71470$f8853d50$@pcorp.us>
 <rmiecia8dck.fsf@s1.lexort.com> <rmi4ij68d17.fsf@s1.lexort.com>
 <000701dcfb6c$23e60870$6bb21950$@pcorp.us> <rmise6q6wna.fsf@s1.lexort.com>
Message-ID: <01ef11a6-209c-4ba2-8e99-4c8b3c9731f7@spatialys.com>

> I really cannot see this as reasonable.  Everyone is all humans, and
> extending it to LLMs seems novel and at best highly controversial.

Strong +1 here. I'm very shocked by statements that LLMs could qualify 
as "someone". Someone obviously involves a biological entity originating 
from human cells.?If we start to acknowledge rights to bots, then 
humanity is in high danger. Especially since ethical AI doesn't exist 
(there might be lab experiments around that, but in practice that's not 
the one people use when they use commercial models). So you're currently 
dealing with things explicitly designed to make human users addict. 
There are numerous testimonies of events where "agents" start leaving 
the framework in which they were initially thought to be restricted and 
play according to their own "intents", and given the high dependence of 
our societies to computer networks, this is deeply concerning.

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.


From gdt at lexort.com  Sat Jun 13 16:14:25 2026
From: gdt at lexort.com (Greg Troxel)
Date: Sat, 13 Jun 2026 19:14:25 -0400
Subject: LLM policy
In-Reply-To: <000201dcfb7e$170c85e0$452591a0$@pcorp.us> (Regina Obe's message
 of "Sat, 13 Jun 2026 17:46:26 -0400")
References: <rmiv7bsj9x5.fsf@s1.lexort.com>
 <CAC8Q8t+bdsivBS-=5v25s-GC4g7oTZfKhXT-Bqmb_yQkGYB2iw@mail.gmail.com>
 <rmibjdea9kt.fsf@s1.lexort.com>
 <000001dcfb68$52d71470$f8853d50$@pcorp.us>
 <rmiecia8dck.fsf@s1.lexort.com> <rmi4ij68d17.fsf@s1.lexort.com>
 <000701dcfb6c$23e60870$6bb21950$@pcorp.us>
 <rmise6q6wna.fsf@s1.lexort.com>
 <01ef11a6-209c-4ba2-8e99-4c8b3c9731f7@spatialys.com>
 <000201dcfb7e$170c85e0$452591a0$@pcorp.us>
Message-ID: <rmifr2q6nji.fsf@s1.lexort.com>

"Regina Obe" <lr at pcorp.us> writes:

> Again I say we can come to the same conclusion by not debating what is
> everyone.

The problem is that this statement accepts that the CoC, which applies
to "everyone", might apply to LLMs as pseudo-people, both as
  - creators of content later submitted
  - autonomous agent submitting content disjoint from a human

The problem is not just disagreement about "are LLMs people too" but the
very concept that a code of conduct can protect probabalistic machine
models from a human choice to prohibit them.  Saying we don't need to
debate it -- without abandoning the assertion -- is a claim that the
opinions of those that find "CoC protects LLMs" to be ludicrous are not
worthy of discussion.

> If a human kills you do you consider them more welcome than AI?  You
> don't need AI to be unethical so the argument seems silly -- just dump
> anthrax in peoples water.  Just throw an A-bomb on a continent. Put
> guards in to prevent the action not the thing or everyone doing it.

This feels like a pile of non-sequiturs.

> I still stand by "you judge the actions not the thing doing it, if you
> have concluded all things of that class are bad, then fine, block all
> those".

Many people have concluded that all extant LLMs are bad.

> If something causes people to be addicts, it's bad period - that could
> be a drug dealer or AI.  I see no point in isolating AI out as if it
> were the only thing capable of evil in this world and simply because
> we deem it not human and therefore not worthy of respect.

LLMs are only being talked about specifically because essentially
everything else you are calling about as bad is near-universally
considered not ok.  For example, if we had people who were interacting
wtih postgis in order to gain trust and plant a vulnerability (xz
style), then we'd say that wasn't ok, and we would almost certainly not
be having a debate.

> My pace-maker could be co-opted, should I be deeply concerned, Yes,
> should I ban the pace-maker from my body? No.

I think it's right to be concerned.  There's a real risk from
proprietary software -- these days I wouldn't really be surprised for a
new pacemaker to be BLE/wifi connected and have the facebook SDK in it
for social login to some portal, with who knows what along for the ride.
There's a real risk that future code updates will embed "AI" which may
or may not make sense (vs neural nets trained on consent-obtained
high-quality data, might already be there).  That's how far I think
people building things have lost their way.  A rant from the best-known
ranter about this:
  https://softwarefreedom.org/resources/2010/transparent-medical-devices.pdf

Do I think you should ban it?  No, of course not, you have to make a
risk/benefit tradeoff, mitigate risks that can be mitigated, and hope
for the best.


But that isn't the question on the table for projects.  It's whether
code produced by LLMs is acceptable, and the reasons it isn't are as you
mentioned upthread: unclear copyright status due to being a derived work
of stolen training data, a track record of being wrong, and transferring
effort from submitters to reviewers/maintainers.

There's a further question, which is if full-on open-loop agent
interaction is acceptable.

(That's before one considers the ethical issues of using LLMs trained on
stolen code, for many, the environment costs of LLMs, and for some, the
coming financial fraud of IPO to index conversion before the bubble
bursts as companies that can't possibly make money fail.  I consider it
unethical to use LLMs that are trained on stolen data or data from
aggressive scraping.  That's a personal judgement, and I realize
opinions differ.)

From lr at pcorp.us  Sat Jun 13 17:29:47 2026
From: lr at pcorp.us (Regina Obe)
Date: Sat, 13 Jun 2026 20:29:47 -0400
Subject: LLM policy
In-Reply-To: <rmifr2q6nji.fsf@s1.lexort.com>
References: <rmiv7bsj9x5.fsf@s1.lexort.com>	<CAC8Q8t+bdsivBS-=5v25s-GC4g7oTZfKhXT-Bqmb_yQkGYB2iw@mail.gmail.com>	<rmibjdea9kt.fsf@s1.lexort.com>	<000001dcfb68$52d71470$f8853d50$@pcorp.us>	<rmiecia8dck.fsf@s1.lexort.com>
 <rmi4ij68d17.fsf@s1.lexort.com>	<000701dcfb6c$23e60870$6bb21950$@pcorp.us>	<rmise6q6wna.fsf@s1.lexort.com>	<01ef11a6-209c-4ba2-8e99-4c8b3c9731f7@spatialys.com>	<000201dcfb7e$170c85e0$452591a0$@pcorp.us>
 <rmifr2q6nji.fsf@s1.lexort.com>
Message-ID: <000001dcfb94$e8851680$b98f4380$@pcorp.us>

Greg and Even,

I think we are mostly in agreement and especially the important points.

> "Regina Obe" <lr at pcorp.us> writes:
> 
> > Again I say we can come to the same conclusion by not debating what is
> > everyone.
> 
> The problem is that this statement accepts that the CoC, which applies to
> "everyone", might apply to LLMs as pseudo-people, both as
>   - creators of content later submitted
>   - autonomous agent submitting content disjoint from a human
> 
> The problem is not just disagreement about "are LLMs people too" but the
> very concept that a code of conduct can protect probabalistic machine
models
> from a human choice to prohibit them.  Saying we don't need to debate it
--
> without abandoning the assertion -- is a claim that the opinions of those
that
> find "CoC protects LLMs" to be ludicrous are not worthy of discussion.
> 

I'm not saying an LLM policy should not be considered so sorry if it sounded
like that was what I was saying.
Yes if the code of conduct (and also our Contributing doc) is not clear
enough, then we need an additional policy specifically for the usage of LLMs
and should probably reference it in those files to be clear.

What I am arguing is the idea that the "everyone" in our code of conduct
means only humans.

I tend to think very anthropomorphically about things and that is
intentional to prevent me from suffering what I consider clouds of
judgement.

For example if we think that everyone refers to people, does that mean I
can't bring my video camera to an event.

I may not be able to bring those things not because they are not human but
because they inconvenience people/things more valued in the community
than they help me and I should be allowed to bring them unless expressly
stated otherwise.  That is a judgement call by the people who are managing
the community or the venue - e.g. someone highly valued in the community
being inconvenienced by a video camera.

Just like other things allowed in, that camera deserves to not be mutilated
by someone who happens to not like cameras. So yes the Coc applies to it, if
I welcome it, it has the same rights as everything else I welcome.

So in that sense the camera has rights.  Our environment has the right not
to be wasted by humans and it isn't human.

Ultimately the purpose of a code of conduct is to help increase the value of
our work for the world in the most efficient way and to welcome valuable
resources into our community.  I don't really see it as being something
specific to humans.

> LLMs are only being talked about specifically because essentially
everything
> else you are calling about as bad is near-universally considered not ok.
For
> example, if we had people who were interacting wtih postgis in order to
gain
> trust and plant a vulnerability (xz style), then we'd say that wasn't ok,
and we
> would almost certainly not be having a debate.
> 

I fail to see the difference here.  Whether it's an LLM trying to gain favor
or a person so they can plant a vulnerability
the conclusion is clear to everyone, it's bad.  I don't need to know it was
an LLM who did it to conclude it is bad
and I'm still going to kick out that one from my community whether it be LLM
or a human because it's bad for my community.


> > My pace-maker could be co-opted, should I be deeply concerned, Yes,
> > should I ban the pace-maker from my body? No.
> 
> I think it's right to be concerned.  There's a real risk from proprietary
software
> -- these days I wouldn't really be surprised for a new pacemaker to be
> BLE/wifi connected and have the facebook SDK in it for social login to
some
> portal, with who knows what along for the ride.
> There's a real risk that future code updates will embed "AI" which may or
may
> not make sense (vs neural nets trained on consent-obtained high-quality
data,
> might already be there).  That's how far I think people building things
have lost
> their way.  A rant from the best-known ranter about this:
>   https://softwarefreedom.org/resources/2010/transparent-medical-
> devices.pdf
> 

Exactly.  We don't need to argue the merits of respecting an AI.
We need to stop bad actors end of story.  If we need to say in our code of
conduct
(we welcome everyone except "You LLM blah blah with link to reason why or
caveats", that's fine.
 
You can say it's easier for an AI to be a bad actor
so you want to deliberately mention and block them or at least a class of AI
you consider hopeless.

> Do I think you should ban it?  No, of course not, you have to make a
> risk/benefit tradeoff, mitigate risks that can be mitigated, and hope for
the
> best.
> 
Agree

> 
> But that isn't the question on the table for projects.  It's whether code
> produced by LLMs is acceptable, and the reasons it isn't are as you
mentioned
> upthread: unclear copyright status due to being a derived work of stolen
> training data, a track record of being wrong, and transferring effort from
> submitters to reviewers/maintainers.
> 
> There's a further question, which is if full-on open-loop agent
interaction is
> acceptable.
> 
Agree, except we don't allow any stolen work period whether it be LLM or
someone who stole code from another project that doesn't allow code copy.

> (That's before one considers the ethical issues of using LLMs trained on
stolen
> code, for many, the environment costs of LLMs, and for some, the coming
> financial fraud of IPO to index conversion before the bubble bursts as
> companies that can't possibly make money fail.  

Agree


I consider it unethical to use
> LLMs that are trained on stolen data or data from aggressive scraping.
That's
> a personal judgement, and I realize opinions differ.)

Agree


From lr at pcorp.us  Sat Jun 13 19:51:53 2026
From: lr at pcorp.us (Regina Obe)
Date: Sat, 13 Jun 2026 22:51:53 -0400
Subject: Meet before releasing PostGIS 3.7.0beta1
References: <000001dcf9da$5be47d80$13ad7880$@pcorp.us>
 <CACowWR0PU4Kfm-PUY_ms6LL5Q0CRBpH+fzfFbttse1tgA+n7_g@mail.gmail.com>
 <aixHqwhj5n6Cjxal@c19.localdomain> 
Message-ID: <000001dcfba8$c2b74360$4825ca20$@pcorp.us>

> I'm going to assume anyone who hasn't responded either can't come or this
> time works:
> 
> June 16th 4 PM UTC
> 
> https://www.timeanddate.com/worldclock/meetingtime.html?iso=20260616
> &p1=43&p2=256&p3=215&p4=371
> 
> So see you all there at June 16th 4 PM UTC  https://meet.osgeo.org/postgis
> 
> Thanks,
> Regina


I've put up an agenda for the meeting:

https://trac.osgeo.org/postgis/wiki/PostGISDevelopment2026-1

Feel free to add any items or go into more detail on any.
I added some items for packagers to consider to make sure our restructuring of code into separate project repos doesn't have any unforeseen consequences for them.

Thanks,
Regina


From gdt at lexort.com  Sun Jun 14 07:39:23 2026
From: gdt at lexort.com (Greg Troxel)
Date: Sun, 14 Jun 2026 10:39:23 -0400
Subject: comments about meeting agenda
In-Reply-To: <000001dcfba8$c2b74360$4825ca20$@pcorp.us> (Regina Obe's message
 of "Sat, 13 Jun 2026 22:51:53 -0400")
References: <000001dcf9da$5be47d80$13ad7880$@pcorp.us>
 <CACowWR0PU4Kfm-PUY_ms6LL5Q0CRBpH+fzfFbttse1tgA+n7_g@mail.gmail.com>
 <aixHqwhj5n6Cjxal@c19.localdomain>
 <000001dcfba8$c2b74360$4825ca20$@pcorp.us>
Message-ID: <rmicxxt5gpw.fsf_-_@s1.lexort.com>

I typically don't attend this sort of thing, and I can't predict
schedule.  I'm addressing the packager items in this note.

* splitting addresss_standardizer and postgis_tiger_geocoder

This is going to cause effort, basically creating two new packages.  If
they have either a normal build system (or the same as postgis or other
pgsql extensions), that will probably not be that much effort.  It's not
clear if "postgis_tiger_geocoder" depends (at build time) on postgis, or
just on pgsql, and idk if there is prior art for extensions that depend
on extensions, and if not, if there are issues.

Users are going to have to add the new packages because when they just
"apt upgrade" or "pkgin up", they are going to get new postgis which
lacks the split components.

We are going to have to sequence all this, so we go from

  - postgis with the extras in the package, to

  - postgis without
  - addresss_standardizer 1.0
  - postgis_tiger_geocoder 1.0

This is a much bigger deal than a regular release.  IMHO it calls for
alpha/beta not just rc, and a substantial time (a month from alpha to
release), more than the normal week from rc to release, because it's not
just doing a build that is widely expected to have zero problems.

Note that I'm saying alpha, not "you can try the repo".  Packaging
systems package releases, not git master branches, and thus the right
thing to work on and test is an alpha which is structurally like a
release, in the same way an rc is.  *What is being tested is the entire
flow from master to binary package, including the process of creating a
release tarball.*

As always, rushing is not ok, so if the split misses the boat, so be it,
because there are no terrible problems and no urgency.

It's good to separate things if

  - They need to have separate release cycles.

  - They have separate schedules for ABI and API breaks (sql is ABI
    because it's a runtime interface, not a compile-against .h
    interface).  Packaging systems need to rebuild depending packages
    when there are ABI breaks.  That's mostly routine, but it must be
    clear when breaks happen, from NEWS.

  - They have different dependencies such that one might want to avoid a
    secondary extension because it has a far bigger requirement

I looked at my package and for the to-be-split extensions I have an
addresss_standardizer shlib (and now tiger geocoder shlib), a README, a
bunch of sql file, and a few .control files.

  184140612	total bytes for postigs and *every pkg it depends on*
   44275036	total bytes for postgis package
    2504225	bytes for standardizer
    2078946	bytes for tiger geocoder

So it's hard to get excited about 4.5 MB in the context of 184 MB, even
though I used Sixth Edition with dual RK05s, I think 5 MB total system
storage.

I can see how people not dealing with US addresses would want to not
install these.  I can see how these are judged "no reason to be part of
postgis".

(The real benefit is splitting things with heavier or difficult
dependencie (sfcgal?), so that people can install postgis plain and
later install those.  I'm unclear on how that collides with reality (and
that's ok).)

All in all, it's not clear to me that the benefits are there, because
I'm not sure how much pain there is now.  I do agree that logically it
would be a good move.  I do not agree that there is urgency, or any
justification for deviating from adequately long alpha cycles.

The first step is to get alpha releases for the split repos, probably
leaving postgis master alone (with an unmerged branch to remove them).
However, I see they are gone from master for months, and I haven't seen
announcements of new repos, and ther are definitely no releases or
alphas.

There are no releases at
  https://github.com/postgis/address_standardizer

There are apparently no releases at

  https://gitea.osgeo.org/postgis/postgis_tiger_geocoder
  (and it looks like pgsql 16+, vs 14+ for postgis)

If you're not ok with getting alphas out and having 30 days from that to
release of new postgis, I think the removal from master should be
reverted, and then alphas and then re-remove from master once the alphas
have survived testing.

* h3-pg

I was unaware of this, and as far as I can tell it's just another
library one could use (and thus one could package), but I don't see how
it relates to postgis or postgis releases.

From gdt at lexort.com  Sun Jun 14 08:28:17 2026
From: gdt at lexort.com (Greg Troxel)
Date: Sun, 14 Jun 2026 11:28:17 -0400
Subject: LLM policy
In-Reply-To: <000001dcfb94$e8851680$b98f4380$@pcorp.us> (Regina Obe's message
 of "Sat, 13 Jun 2026 20:29:47 -0400")
References: <rmiv7bsj9x5.fsf@s1.lexort.com>
 <CAC8Q8t+bdsivBS-=5v25s-GC4g7oTZfKhXT-Bqmb_yQkGYB2iw@mail.gmail.com>
 <rmibjdea9kt.fsf@s1.lexort.com>
 <000001dcfb68$52d71470$f8853d50$@pcorp.us>
 <rmiecia8dck.fsf@s1.lexort.com> <rmi4ij68d17.fsf@s1.lexort.com>
 <000701dcfb6c$23e60870$6bb21950$@pcorp.us>
 <rmise6q6wna.fsf@s1.lexort.com>
 <01ef11a6-209c-4ba2-8e99-4c8b3c9731f7@spatialys.com>
 <000201dcfb7e$170c85e0$452591a0$@pcorp.us>
 <rmifr2q6nji.fsf@s1.lexort.com>
 <000001dcfb94$e8851680$b98f4380$@pcorp.us>
Message-ID: <rmimrwx3zvy.fsf@s1.lexort.com>

"Regina Obe" <lr at pcorp.us> writes:

I'm going to try to be brief about the larger CoC discussion.

> For example if we think that everyone refers to people, does that mean I
> can't bring my video camera to an event.

It means that the CoC does not say it's improper for an event to say no
cameras.  It means that you have no basis for a CoC complaint when there
is such a rule and you don't like it.  It means that cameras are not
entities receiving protection.

Sort of related, fairly typical CoC (conference specific) says everyone
(humans) has the right not to be recorded, or invasively recorded.

> Just like other things allowed in, that camera deserves to not be mutilated
> by someone who happens to not like cameras.

The standard view is that it is improper to destroy other people's
things.  This is generally law, so the CoC is redundant.  You are of
course welcome to your view that "[object] deserves", but I see that as
very unusual and not generally accepted.

> Ultimately the purpose of a code of conduct is to help increase the value of
> our work for the world in the most efficient way and to welcome valuable
> resources into our community.

Some think that, and some see it as a codification of a group norm of
courteous and non-discriminatory behavior because that courtesy is
morally correct independent of whether it helps the project's value or
it doesn't.  (The reality is uglier, but I'll leave it as theory.)

>> LLMs are only being talked about specifically because essentially
>> everything else you are calling about as bad is near-universally
>> considered not ok.  For example, if we had people who were
>> interacting wtih postgis in order to gain trust and plant a
>> vulnerability (xz style), then we'd say that wasn't ok, and we would
>> almost certainly not be having a debate.
>
> I fail to see the difference here.

I just meant that there are behaviors outside our existing norms, and we
don't talk about them much because we all agree the behaviors are not
ok.

LLM use is under discussion because some think it is outside existing
norms or that it should be outside norms, and some think it's ok.

> Agree, except we don't allow any stolen work period whether it be LLM or
> someone who stole code from another project that doesn't allow code copy.

Then, I think we agree that under *the project's existing rules*

  1) any code which was not written by the submitter must be identified
     as such, with a stated author/authors, and submitted only if all
     those authors have consented to licensing the contribution under
     the project's license.

  2) LLM-generated code is not acceptable, unless it was generated

     a) by a model using only training data that is licensed for LLM use
        *which includes permission to reuse without attribution or any
        licensing text*, and includes only data for which there is true
        consent, not via a fraudulent claim of expected-not-to-be-read
        clickthrough license as part of some larger service

     b) (probably, but arguably the existing rules do not prohibit
        antisocial behavior by contributors) not produced by an
        organization that engages in abusive scraping.  Arguably abusive
        scraping is a CoC violation as it is harassment of humans who
        manage other web systems, and/or vandalism.

Because there are not any code-generating LLMs that meet 2(a) it follows
that LLM contributions to the project are not allowed.

This should then be straightforwardly clarified, as those that like
using LLMs seem to be willing to adopt differing interpretations of
existing rules.

From lr at pcorp.us  Sun Jun 14 13:16:18 2026
From: lr at pcorp.us (Regina Obe)
Date: Sun, 14 Jun 2026 16:16:18 -0400
Subject: comments about meeting agenda
In-Reply-To: <rmicxxt5gpw.fsf_-_@s1.lexort.com>
References: <000001dcf9da$5be47d80$13ad7880$@pcorp.us>
 <CACowWR0PU4Kfm-PUY_ms6LL5Q0CRBpH+fzfFbttse1tgA+n7_g@mail.gmail.com>
 <aixHqwhj5n6Cjxal@c19.localdomain> <000001dcfba8$c2b74360$4825ca20$@pcorp.us>
 <rmicxxt5gpw.fsf_-_@s1.lexort.com>
Message-ID: <000001dcfc3a$a97852d0$fc68f870$@pcorp.us>

> I typically don't attend this sort of thing, and I can't predict schedule.
I'm
> addressing the packager items in this note.
> 
> * splitting addresss_standardizer and postgis_tiger_geocoder
> 
> This is going to cause effort, basically creating two new packages.  If
they have
> either a normal build system (or the same as postgis or other pgsql
> extensions), that will probably not be that much effort.  It's not clear
if
> "postgis_tiger_geocoder" depends (at build time) on postgis, or just on
pgsql,
> and idk if there is prior art for extensions that depend on extensions,
and if
> not, if there are issues.
> 

There is prior art.

address_standardizer does not depend on PostGIS at all and uses the
PostgreSQL general build system.  So a bit simpler than postgis tool chain,
which was one reason to break it from postgis core.

postgis_tiger_geocoder is all plgsql code so it will build without postgis,
but the install-check will fail unless postgis is installed. 
I think this is pretty similar to other extensions that rely on postgis not
packaged with postgis  -- e.g. pgrouting
https://github.com/pgRouting/pgrouting 
Again postgis_tiger_geocoder used the PostgreSQL install-check build chain,
so the simplicity was reduced a bit by separating it out of postgis.

It has a  conditional dependence on address_standardizer.
The address_standardizer part is exercised in tests only if you choose it as
a dependency.  Ultimately whether you test with or without doesn't matter.
It doesn't impact the built package.

This conditional dependency on address_standardizer is similar to the
conditional dependency that https://github.com/pramsey/pgsql-ogr-fdw has on
postgis.

> Users are going to have to add the new packages because when they just
"apt
> upgrade" or "pkgin up", they are going to get new postgis which lacks the
split
> components.
> 
> We are going to have to sequence all this, so we go from
> 
>   - postgis with the extras in the package, to
> 
>   - postgis without
>   - addresss_standardizer 1.0
>   - postgis_tiger_geocoder 1.0
> 

Ah good point.  I completely forgot about the user experience.  So we should
note that in the PostGIS 3.7.0 release notes once we have an idea what
packagers will do.
A good portion of our users now are on DbaaS, so most likely assuming the
DbaaS packagers do their job right, this change should be transparent to
them because they'll only have to worry about  CREATE EXTENSION
address_standardizer;  etc which they had to do already anyway.

> This is a much bigger deal than a regular release.  IMHO it calls for
alpha/beta
> not just rc, and a substantial time (a month from alpha to release), more
than
> the normal week from rc to release, because it's not just doing a build
that is
> widely expected to have zero problems.
> 

I was debating that. Okay will change to have an alpha first.


> Note that I'm saying alpha, not "you can try the repo".  Packaging systems
> package releases, not git master branches, and thus the right thing to
work on
> and test is an alpha which is structurally like a release, in the same way
an rc
> is.  *What is being tested is the entire flow from master to binary
package,
> including the process of creating a release tarball.*
> 
> As always, rushing is not ok, so if the split misses the boat, so be it,
because
> there are no terrible problems and no urgency.
> 
Well I feel otherwise cause missing the boat means having an additional year
to support old versions.


> It's good to separate things if
> 
>   - They need to have separate release cycles.
> 
>   - They have separate schedules for ABI and API breaks (sql is ABI
>     because it's a runtime interface, not a compile-against .h
>     interface).  Packaging systems need to rebuild depending packages
>     when there are ABI breaks.  That's mostly routine, but it must be
>     clear when breaks happen, from NEWS.
> 
>   - They have different dependencies such that one might want to avoid a
>     secondary extension because it has a far bigger requirement
> 
> I looked at my package and for the to-be-split extensions I have an
> addresss_standardizer shlib (and now tiger geocoder shlib), a README, a
> bunch of sql file, and a few .control files.
> 
>   184140612	total bytes for postigs and *every pkg it depends on*
>    44275036	total bytes for postgis package
>     2504225	bytes for standardizer
>     2078946	bytes for tiger geocoder
> 
> So it's hard to get excited about 4.5 MB in the context of 184 MB, even
though
> I used Sixth Edition with dual RK05s, I think 5 MB total system storage.
> 
> I can see how people not dealing with US addresses would want to not
install
> these.  I can see how these are judged "no reason to be part of postgis".
>
Yah the main reason is not because of size, but because
a) the release cycle is very different - address_standardizer rarely changes
except for security fixes and postgis_tiger_geocoder - aside from security
fixes only changes around September when US Census comes out with a new data
set.
b) Both have much simpler tooling than postgis proper.  They both just
follow the more simplistic PostgreSQL install-make check
So this means we can probably ship these on pgxn as well since their
make/install tooling is much simpler.

c) the other reason is postgis_tiger_geocoder is US centric, so really
doesn't belong in a package designed for a global user base.
I expect in future we may have other geocoders that are for example
openstreetmap centric that you can use with just PostgreSQL (no middleware).
In the case of address_standardizer true it is pretty US but in theory with
additional data dictionaries it can handle other countries and there is an
address_standardizer-2 that Steve Woodbrdige was working on before he
retired that does have dictionaries for Germany and had much more
flexibility.  That one had a dependency on boost regex so I didn't want it
part of postgis. That one I may resuscitate and pull into PostGIS org.

> (The real benefit is splitting things with heavier or difficult
dependencie
> (sfcgal?), so that people can install postgis plain and later install
those.  I'm
> unclear on how that collides with reality (and that's ok).)
> 
They can do that already by just doing --without-sfcgal  and postgis_sfcgal
does have an intimate dependency with liblwgeom and rest of postgis geometry
structures and does closely follow the postgis release cycle, so I think
that is a much trickier proposition and less desirable to do.
We already did split sfcgal function from the postgis lib file since having
another extension postgis_sfcgal that shared the same postgis lib was
confusing and would break should you decide next time not to build with
postgis_sfcgal support.

It also made the set of live functions in our postgis lib file  be
consistent regardless if you choose to compile with or without sfcgal.

> All in all, it's not clear to me that the benefits are there, because I'm
not sure
> how much pain there is now.  I do agree that logically it would be a good
> move.  I do not agree that there is urgency, or any justification for
deviating
> from adequately long alpha cycles.
> 
I expect there will be slight pain in the beginning but I think in the long
run it's best for all extensions involved.

Both postgis_tiger_geocoder and address_standardizer do not have to suffer
the same more frequent release cycle.
Also since their dependencies are much simpler, it may encourage others to
contribute who wouldn't have bothered because postgis repo is such an
intimidating beast.


> The first step is to get alpha releases for the split repos, probably
leaving
> postgis master alone (with an unmerged branch to remove them).
We already removed these from master and we aren't turning back on that.

Yes we can have an alpha I'm in agreement on that now I've heard your
concerns.

> However, I see they are gone from master for months, and I haven't seen
> announcements of new repos, and ther are definitely no releases or alphas.
> 
I recall we made mention of this on postgis-devel a couple of times and Paul
did just last week.
I don't expect packagers to pay much attention to this especially until we
release.

> There are no releases at
>   https://github.com/postgis/address_standardizer

> 
> There are apparently no releases at
> 
>   https://gitea.osgeo.org/postgis/postgis_tiger_geocoder
>   (and it looks like pgsql 16+, vs 14+ for postgis)
> 
Exactly postgis_tiger_geocoder requires 16+ because it's using functionality
I authored for PostgreSQL 16 and above to allow schema qualification of
dependent extensions -
https://www.postgresql.org/message-id/flat/20230118214223.2crj7hh3i5amzkji%4
0c19#c4f1683db08df216eedb91ad9de2b12b

I debated supporting 15 but it will make the build slightly more complicated
since I'd have to put in conditionals.

PG14 is going to be EOL soon so there is no point supporting it.  I also
figure most packagers aren't going to be building 3.7 for PostgreSQL 15 that
they'll just stick with 3.6 or lower.

I'm planning to release a postgis_tiger_geocoder this month and I believe
Paul is planning to release address_standardizer as well this  month,
probably a little before we do the PostGIS 3.7.0alpha1.


> If you're not ok with getting alphas out and having 30 days from that to
release
> of new postgis, I think the removal from master should be reverted, and
then
> alphas and then re-remove from master once the alphas have survived
> testing.
I expect PostgreSQL 19 to come out in September, so I think we can do the
30day thing.  Perhaps slightly shorter.

> 
> * h3-pg
> 
> I was unaware of this, and as far as I can tell it's just another library
one could
> use (and thus one could package), but I don't see how it relates to
postgis or
> postgis releases.

The only difference is that h3-pg moved from the original maintainer to
postgis ORG on github.  The original maintainer didn't have time to work on
it anymore and since it's a fairly popular extension, we adopted it.

It's much the same story why https://github.com/postgis/docker-postgis lives
under the PostGIS org.  We adopted it from the original maintainer.

Thanks for your input,
Regina


From lr at pcorp.us  Sun Jun 14 13:54:14 2026
From: lr at pcorp.us (Regina Obe)
Date: Sun, 14 Jun 2026 16:54:14 -0400
Subject: LLM policy
In-Reply-To: <rmimrwx3zvy.fsf@s1.lexort.com>
References: <rmiv7bsj9x5.fsf@s1.lexort.com>	<CAC8Q8t+bdsivBS-=5v25s-GC4g7oTZfKhXT-Bqmb_yQkGYB2iw@mail.gmail.com>	<rmibjdea9kt.fsf@s1.lexort.com>	<000001dcfb68$52d71470$f8853d50$@pcorp.us>	<rmiecia8dck.fsf@s1.lexort.com>
 <rmi4ij68d17.fsf@s1.lexort.com>	<000701dcfb6c$23e60870$6bb21950$@pcorp.us>	<rmise6q6wna.fsf@s1.lexort.com>	<01ef11a6-209c-4ba2-8e99-4c8b3c9731f7@spatialys.com>	<000201dcfb7e$170c85e0$452591a0$@pcorp.us>	<rmifr2q6nji.fsf@s1.lexort.com>	<000001dcfb94$e8851680$b98f4380$@pcorp.us>
 <rmimrwx3zvy.fsf@s1.lexort.com>
Message-ID: <000701dcfc3f$f6f8ec40$e4eac4c0$@pcorp.us>

> From: Greg Troxel 


> > Ultimately the purpose of a code of conduct is to help increase the
> > value of our work for the world in the most efficient way and to
> > welcome valuable resources into our community.
> 
> Some think that, and some see it as a codification of a group norm of
> courteous and non-discriminatory behavior because that courtesy is morally
> correct independent of whether it helps the project's value or it doesn't.
(The
> reality is uglier, but I'll leave it as theory.)

Morality is such a subjective thing.  If I can't explain why I think
something is immoral I'd rather not bring morality into the equation.
Just saying something is immoral seems to be a common way for people to shut
down conversation of dissenting opinions.

Is capital punishment immoral?  I really don't care cause it's not part of
my equation as to why or why not it should be done.

Most things I think of as immoral are because I can qualify the damage they
do for my community or the world, not because I have a list of what is moral
and immoral.

Since my project is supposed to be a common good to better the world,
anything that is bad for the world is bad for my project too.  Ergo no point
in bringing morality into the conversation.  Yes postgis can be used for
immoral things like sending drones to kill people, but sadly that is out of
my scope of influence. 

> 
> >> LLMs are only being talked about specifically because essentially
> >> everything else you are calling about as bad is near-universally
> >> considered not ok. 
Most things in Coc should be fairly obvious to everyone, but we still state
it 
because what is obvious to us is not necessarily obvious to someone else.

> LLM use is under discussion because some think it is outside existing
norms or
> that it should be outside norms, and some think it's ok.
> 
Agree and I think it should be treated exactly like all existing norms.
It's no different than when we discussed is it okay for users to use
computers or calculators during exams.
It's okay if all have access to the same tools, but when there is unfair
advantage that is bad for the community at large.
That is something we should focus on even if we can't quite level the
playing field.

By unfair I mean a large company co-opting a project just cause they have
immense processing power and then using it for their own needs.


> > Agree, except we don't allow any stolen work period whether it be LLM
> > or someone who stole code from another project that doesn't allow code
> copy.
> 
> Then, I think we agree that under *the project's existing rules*
> 
>   1) any code which was not written by the submitter must be identified
>      as such, with a stated author/authors, and submitted only if all
>      those authors have consented to licensing the contribution under
>      the project's license.
> 
Agree and if an LLM helped you author it you should say so in your
submission, just as you would credit any author.
Treating an LLM as a proxy human works perfectly here.

>   2) LLM-generated code is not acceptable, unless it was generated
> 
>      a) by a model using only training data that is licensed for LLM use
>         *which includes permission to reuse without attribution or any
>         licensing text*, and includes only data for which there is true
>         consent, not via a fraudulent claim of expected-not-to-be-read
>         clickthrough license as part of some larger service
> 
Disagree.  There is such a thing as fair use, and I think if you look at
legal docs

Eg. The Anthropic case which I am a plaintiff of you will see that.

For example if I read a book on C that I bought and I learn how to write C
from it. Then I apply my new knowledge to provide a patch for PostGIS.
How is this different from an AI reading the same book that its owner
purchased and gleaning the same knowledge. Neither is using code verbatim
from the book.

There is nothing to my knowledge that says licensed to LLM.  If you have
such a reference I would like to see that.

Yes if an LLM takes verbatim code from a GPL project or a private repository
whatever and provides it then that is wrong, as it would be wrong for a
human to do so.
Most coding LLMs do provide a note that yes you can use code generated by
LLM and give provisions under what conditions.

If a project explicitly says, no LLMs can read my code, that too is a clear
violation of an LLM if it doesn't abide by that requirement.
Just as if you called out my name "All are free to use my code except Regina
Obe".


>      b) (probably, but arguably the existing rules do not prohibit
>         antisocial behavior by contributors) not produced by an
>         organization that engages in abusive scraping.  Arguably abusive
>         scraping is a CoC violation as it is harassment of humans who
>         manage other web systems, and/or vandalism.
> 
> Because there are not any code-generating LLMs that meet 2(a) it follows
that
> LLM contributions to the project are not allowed.
> 
> This should then be straightforwardly clarified, as those that like using
LLMs
> seem to be willing to adopt differing interpretations of existing rules.

As mentioned I don't agree with your 2 (a) 
I do agree that if your code is not fully your own, you should state the
additional authors, an LLM is an author like any other and deserves to be
attributed.
And that you have proof you have right to use such code -- again the LLM use
contract.




From gdt at lexort.com  Sun Jun 14 15:33:00 2026
From: gdt at lexort.com (Greg Troxel)
Date: Sun, 14 Jun 2026 18:33:00 -0400
Subject: comments about meeting agenda
In-Reply-To: <000001dcfc3a$a97852d0$fc68f870$@pcorp.us> (Regina Obe's message
 of "Sun, 14 Jun 2026 16:16:18 -0400")
References: <000001dcf9da$5be47d80$13ad7880$@pcorp.us>
 <CACowWR0PU4Kfm-PUY_ms6LL5Q0CRBpH+fzfFbttse1tgA+n7_g@mail.gmail.com>
 <aixHqwhj5n6Cjxal@c19.localdomain>
 <000001dcfba8$c2b74360$4825ca20$@pcorp.us>
 <rmicxxt5gpw.fsf_-_@s1.lexort.com>
 <000001dcfc3a$a97852d0$fc68f870$@pcorp.us>
Message-ID: <rmia4sw3g83.fsf@s1.lexort.com>

"Regina Obe" <lr at pcorp.us> writes:

>> Note that I'm saying alpha, not "you can try the repo".  Packaging
>> systems package releases, not git master branches, and thus the right
>> thing to work on and test is an alpha which is structurally like a
>> release, in the same way an rc is.  *What is being tested is the
>> entire flow from master to binary package, including the process of
>> creating a release tarball.*
>> 
>> As always, rushing is not ok, so if the split misses the boat, so be
>> it, because there are no terrible problems and no urgency.
>
> Well I feel otherwise cause missing the boat means having an
> additional year to support old versions.

If it's important now it was important to start on time!
I don't think it's ok to cause churn to innocent bystanders by doing
things hastily that don't need to be done hastily.  But it seems there
is enough time, so let's not worry about that.

>> (The real benefit is splitting things with heavier or difficult
>> dependencie (sfcgal?), so that people can install postgis plain and
>> later install those.  I'm unclear on how that collides with reality
>> (and that's ok).)
> 
> They can do that already by just doing --without-sfcgal  and postgis_sfcgal
> does have an intimate dependency with liblwgeom and rest of postgis geometry
> structures and does closely follow the postgis release cycle, so I think
> that is a much trickier proposition and less desirable to do.
> We already did split sfcgal function from the postgis lib file since having
> another extension postgis_sfcgal that shared the same postgis lib was
> confusing and would break should you decide next time not to build with
> postgis_sfcgal support.

Not going to worry about this now, but I don't mean disabling features,
I mean the kind of move-to-another-repo split.

>> However, I see they are gone from master for months, and I haven't seen
>> announcements of new repos, and ther are definitely no releases or alphas.
> 
> I recall we made mention of this on postgis-devel a couple of times
> and Paul did just last week.  I don't expect packagers to pay much
> attention to this especially until we release.

I probably missed it, and probably that's my fault, but it likely seemed
like "we are going to release this".  What's needed is a message that
announces that there is an alpha (downloadable tarballs), and requests
packagers to create and test packages for those repos.  That's much more
work than an update, and I'm not complaining about it it's just not
something that will happen in the usual "here's an rc, and we're going
to move to release it 2 days later".

As far as not paying attention until release, until there's an
alpha/beta/rc, there is nothing to package.  You have to meet people
where they should be, rather than deciding they won't do anything.

And, I would think a lot of packagers test the rc releases, and just
don't say anything when they are fine.  I have set up variables to
accomodate rcs in terms of where the names do and don't change, so I can
test them quickly.  That moves most of the work from release time to rc
time (new/changed files being installed, anything else), and the work at
actual release is basically just commenting out the variable that
defines "rc1".

> I'm planning to release a postgis_tiger_geocoder this month and I believe
> Paul is planning to release address_standardizer as well this  month,
> probably a little before we do the PostGIS 3.7.0alpha1.

Thanks.  I see them as really overdue already, being gone from master.
The long pole in the tent is

  1. get release infrastructure in place for the extensions,
     either scripts or CI
  2. debug release infrastructure
  3. jump back to 1 if trouble
  4. actually tag and alpha and release a tarball
  5. packagers start working with the tarball to make package
  6. problems found, analyzed, discussed
  7. if so, jump back to 2
  8. finally we have a release tarball and a package that are ok

This is why I said 30 days.  There's a lot that's new and a lot that can
go wrong, and most people that do packaging do it in spare time.

I think postgis should have an alpha, but the timing is less critical
there.  I expect that the release tarball process will not be messed up
by the removals, or if so it will be easy to fix.  I expect the package
build process will just not install those things, and there will be
minor issues like having to drop --enable-address-standardizer from the
build control files, and then adjusting the list of installed files.
That's all minor and pretty low risk.

So it was about the new ones that I think people should have a whole
month to iterate.

> The only difference is that h3-pg moved from the original maintainer to
> postgis ORG on github.  The original maintainer didn't have time to work on
> it anymore and since it's a fairly popular extension, we adopted it.

Ah, so if we had a package, then we'd just update the HOMEPAGE and
MASTER_SITES.  pkgsrc doesn't (not a choice but a happenstance).

I think this should be ok, then, but the clock is ticking and alpha
sooner rather than later.  Lots of stuff can be rough - it's really the
"make tarball" and "build/install from tarball" that's critical.

From strk at kbt.io  Mon Jun 15 23:42:14 2026
From: strk at kbt.io (Sandro Santilli)
Date: Tue, 16 Jun 2026 08:42:14 +0200
Subject: LLM policy
In-Reply-To: <rmi7bo2a9d3.fsf@s1.lexort.com>
References: <rmiv7bsj9x5.fsf@s1.lexort.com>
 <CAC8Q8t+bdsivBS-=5v25s-GC4g7oTZfKhXT-Bqmb_yQkGYB2iw@mail.gmail.com>
 <aixNHn1P8KClO4gy@c19.localdomain> <rmi7bo2a9d3.fsf@s1.lexort.com>
Message-ID: <ajDwRjrgEU6Fu1JF@c19.localdomain>

On Sat, Jun 13, 2026 at 08:54:48AM -0400, Greg Troxel wrote:
> Sandro Santilli <strk at kbt.io> writes:
> 
> > On Tue, Jun 09, 2026 at 05:10:51PM +0400, Darafei "Kom?pa" Praliaskouski wrote:
> >
> >> I believe AIs are covered by existing diversity statement of code of conduct:
> >> https://postgis.net/community/conduct/#diversity-statement
> >
> > I agree on not defining a policy about which tools you can use to
> > contribute to PostGIS.
> 
> It's not really about "tools you can use", but about input without
> proper licensing (models trained on stolen code)

I know I'm guilty of having contributed PostGIS code by copying what
I learnt by watching other people's code, and I'm grateful to those
who published that code for me to watch, and allowed me to even copy
that code by sharing the resulting code with the same license.

Should I call that stealing ?

> and about overly
> verbose input that is particularly hard to review because of an
> established pattern of subtle errors while seeming plausible.

Both overly verbose input and malicious code could also come from
humans,remmeber the xz-utils backdoor (CVE-2024-3094) ?

> > We need to be always careful about what we merge, and if it's too
> > difficult to review a contribution, we should not feel pressured to
> > accept it.
> 
> Under that, the response to most LLM contributions should be to reject
> them as too verbose, unless they are as tightly written as accepted
> human-authored contributions.  And, to reject contributions that have a
> hint of not being understand by the human submitter as well as one that
> was constructed without LLM.  This is not quite a ban, but in practice
> it's pretty close.

I think in general we should ONLY accept contribution when we're willing
to take on responsibility over what we're merging. If a contributor
doesn't understand the consequences of their contributions it is still
possible that a manintainer would want to merge it because it's well
understood by her/him.

> > Shall communication become too verbose we'll see how to approach that
> > problem, maybe we're not affected because there aren't many Coding Agents
> > capable of filing Trac tickets ;)
> 
> The problematic merge request I saw was filed by a human but the code
> changes were generated by an LLM.
> 
> I suggest looking over the gdal-dev list and Even's comments after
> trying to deal with LLM inputs.

I've been reading complains about the overload on the Fediverse and I
do symphatize with those maintainers. Me personally I don't even look
at GitHub filed pull requests without a corresponding Trac ticket and
even in that case I only review code if a contribution interests me
for some reason (intellectual, fun, work).

Citing Even's signature: "my software is free but my time generally isn't".

--strk; 

  Libre GIS consultant/developer ?
  https://strk.kbt.io/services.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260616/4025ccde/attachment.sig>

From strk at kbt.io  Tue Jun 16 01:46:58 2026
From: strk at kbt.io ('Sandro Santilli')
Date: Tue, 16 Jun 2026 10:46:58 +0200
Subject: Docs Format
In-Reply-To: <000801dcfb6d$56df3cf0$049db6d0$@pcorp.us>
References: <CACowWR2Fy2Jz5PUEgBpqSFfFwOhb4L0vcPAqmkgUppFPMmo6cg@mail.gmail.com>
 <aixN1Mp6EGaI5F4h@c19.localdomain>
 <17B755E2-4DE2-4A4E-9951-8863EA17E385@cleverelephant.ca>
 <000801dcfb6d$56df3cf0$049db6d0$@pcorp.us>
Message-ID: <ajENgo672tlm_AvG@c19.localdomain>

On Sat, Jun 13, 2026 at 03:46:32PM -0400, Regina Obe wrote:

> I do see Darafei's point about the docs in source being hard to navigate.  That seems to be the most fundamental problem and would like it if we can solve in other ways.
> Like I mentioned in matrix/irc, perhaps putting a link on the viewable docs to the xml file it belongs.  

That would be great, filename and ideally line number !

Then one day I'd want to further split source files to make it easier to deal with (like a topology/ subdir with an xml for ach function or so..)

--strk;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260616/544805bf/attachment.sig>

From lr at pcorp.us  Tue Jun 16 07:48:24 2026
From: lr at pcorp.us (Regina Obe)
Date: Tue, 16 Jun 2026 10:48:24 -0400
Subject: Docs Format
In-Reply-To: <ajENgo672tlm_AvG@c19.localdomain>
References: <CACowWR2Fy2Jz5PUEgBpqSFfFwOhb4L0vcPAqmkgUppFPMmo6cg@mail.gmail.com>
 <aixN1Mp6EGaI5F4h@c19.localdomain>
 <17B755E2-4DE2-4A4E-9951-8863EA17E385@cleverelephant.ca>
 <000801dcfb6d$56df3cf0$049db6d0$@pcorp.us> <ajENgo672tlm_AvG@c19.localdomain>
Message-ID: <008d01dcfd9f$2f9a48e0$8ecedaa0$@pcorp.us>

> Then one day I'd want to further split source files to make it easier to
deal
> with (like a topology/ subdir with an xml for ach function or so..)
> 
> --strk;

Yuck


From pella.samu at gmail.com  Tue Jun 16 08:36:50 2026
From: pella.samu at gmail.com (Imre Samu)
Date: Tue, 16 Jun 2026 17:36:50 +0200
Subject: LLM policy
In-Reply-To: <rmiv7bsj9x5.fsf@s1.lexort.com>
References: <rmiv7bsj9x5.fsf@s1.lexort.com>
Message-ID: <CAJnEWw=nZuN7Wrj6PgwaAUKoarwmBmLwQF7AyxOeTz+VDEkwOw@mail.gmail.com>

Greg Troxel <gdt at lexort.com> ezt ?rta (id?pont: 2026. j?n. 9., K, 12:16):

> Regardless of how the consensus ends up



Since consensus on a main-repository AI/LLM policy seems difficult right
now, I propose an experimental compromise:
- create *a separate "postgis-agentic-lab" repository* !
It would allow AI/agentic experimentation without adding noise or review
pressure to the main postgis repo.
It would create no obligation for maintainers, but useful results could be
manually extracted by a human postgis maintainer and submitted upstream
through the normal process.

So some postgis users may be able to contribute not only bug reports, but
also AI-assisted candidate solutions. ( Fable/Mythos welcome )
Even if these are not accepted upstream, they may still be useful to other
postgis users with similar issues.

Imre / wearing my postgis power user hat /


=====================

*Proposal: ~ `postgis-agentic-lab`*
( brainstormed with Chatgpt-5.5-High )

The goal is to ensure that AI-assisted work demonstrably reduces, rather
than increases, the maintenance burden on PostGIS maintainers.

*Main PostGIS repository*
- Only human contributors may submit upstream issues, pull requests, review
comments, or mailing list messages.
- *Existing trusted postgis commiters/contributors may use AI assistance f*or
small, reviewable changes, preferably under a soft limit such as ~50-100
changed lines. ( new contributors with AI --> `postgis-agentic-lab` )
-  Substantial AI assistance must be disclosed, including the tool/model
used where relevant.
-  The human contributor remains fully responsible for understanding,
testing, licensing, and maintaining the contribution.
-  Any `AGENTS.md`, skills, prompts, or agentic instructions in the main
repository should clearly say *that agentic experiments belong in
`postgis-agentic-lab`,* not in the main repository. ( including postgis
end-users agentic code suggestions , fix )
- Autonomous agents must not act directly in official PostGIS project
spaces.

*Postgis-Agentic-lab  repository:*
-  Create a new fork* `github.com/postgis/postgis-agentic-lab
<http://github.com/postgis/postgis-agentic-lab>*` as* an experimental AI
staging/lab repository for postgis*
-  The lab is for AI-assisted reproduction, testing, analysis,
benchmarking, patch prototyping, prompt sharing, and agentic workflow
experiments.
-  The lab is continuously synchronized from the main PostGIS repository,
but nothing flows back automatically.
-  AI agents and human+agent workflows may create issues and pull requests
there under special rules.
*-  Work in the lab creates no obligation for PostGIS maintainers to
review, respond, accept, or merge anything.*
-  Stale lab issues/PRs without a human owner or clear progress may be
*automatically
closed after 30 days.*
*-  Agentic tools such as openclaw, hermes, or similar systems should work
in this lab repository, not directly against the main PostGIS repository.*

*Supported use cases in the lab*
- Generate a minimal, reproducible, human-friendly bug report from a
real-world problem ( by the postgis-end users or agents  )
- Sanitize and reduce private or company data into a safe public reproducer.
- Create a failing new PostGIS regression test as a separate commit.
- Analyze the root cause and document competing hypotheses.
- Create a detailed fix prompt for a general AI coding agent.
- Produce a candidate patch as a separate commit.
- Document test results, benchmark methodology, and performance impact.
- Share useful prompts, agent instructions, negative results, and failed
approaches.
- ....

*Contribution categories in the agentic-lab:*
- "Supported": reproducible bug reports, minimized test cases, benchmarks,
root-cause analysis, documentation of methodology.
- "Accepted for human upstreaming":  small, tested, human-owned patches
with clear provenance and AI disclosure.
- "Tolerated / prototype" : speculative fixes, large refactors,
experimental prompts, agent-generated ideas, incomplete prototypes.
- "Forbidden": autonomous / generated spam, hallucinated test results,
undisclosed private data, unclear license provenance, or any change the
human owner cannot explain.

*Upstream promotion rule*
- The lab is not an official upstream contribution queue.
- Only a human trusted postgis committer may manually prepare and submit a
final PR to `postgis/postgis`.
- The upstream PR must be small, reviewable, tested, disclose substantial
AI assistance, and link back to the relevant lab artifact if useful.
- Ideally, the upstream PR should contain the prompts and:
     - one commit for the failing test,
     - one commit for the fix,
     - optional documentation or benchmark notes.

etc.
=====
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260616/d5210e4c/attachment.htm>

From lr at pcorp.us  Tue Jun 16 23:34:32 2026
From: lr at pcorp.us (Regina Obe)
Date: Wed, 17 Jun 2026 02:34:32 -0400
Subject: PostGIS Dev Meeting notes
Message-ID: <000a01dcfe23$5c8e91b0$15abb510$@pcorp.us>

I want to thank all of you who attended the PostGIS Dev meeting.  We had a
good turnout.  I think it was a pretty productive meeting.
We had a couple of packagers attend and Devrim was particularly helpful in
explaining options for packaging and how PGDG packaging works.

We had some shy people or they couldn't hear not sure.  So unfortunately we
didn't hear from all the people we wanted to hear from but attending was a
good first step and hopefully even though many were quiet, they were able to
listen and are okay with our direction.

The meeting notes are here:
https://trac.osgeo.org/postgis/wiki/PostGISDevelopment2026-1  feel free to
add your name to the attendance roster if you attended or add additional
notes I may have missed.

Thanks,
Regina



From strk at kbt.io  Wed Jun 17 05:35:36 2026
From: strk at kbt.io (Sandro Santilli)
Date: Wed, 17 Jun 2026 14:35:36 +0200
Subject: comments about meeting agenda
In-Reply-To: <rmicxxt5gpw.fsf_-_@s1.lexort.com>
References: <000001dcf9da$5be47d80$13ad7880$@pcorp.us>
 <CACowWR0PU4Kfm-PUY_ms6LL5Q0CRBpH+fzfFbttse1tgA+n7_g@mail.gmail.com>
 <aixHqwhj5n6Cjxal@c19.localdomain> <000001dcfba8$c2b74360$4825ca20$@pcorp.us>
 <rmicxxt5gpw.fsf_-_@s1.lexort.com>
Message-ID: <B40C7892-1180-4CC6-B9D1-F80375FEA53F@kbt.io>

Replying inline 

(email is more accessible for everyone, compared with meetings, I'd like to have more of email and less meetings)


Il 14 giugno 2026 16:39:23 CEST, Greg Troxel <gdt at lexort.com> ha scritto:

>(The real benefit is splitting things with heavier or difficult
>dependencie (sfcgal?), so that people can install postgis plain and
>later install those.  


We discussed this at the meeting and we agreed we're happy with packagers providing separate packages for SFCGAL and Raster extensions. We didn't mention at the meeting but I'm also happy with separate postgis topology package.

Even if small, at least you save the space taken by all those silly upgrade script symlinks (assuming they remain symlinks upon packaging).

-- 
Sent from hand-held device with K-9 Mail. Please excuse my brevity.

From gdt at lexort.com  Wed Jun 17 05:42:32 2026
From: gdt at lexort.com (Greg Troxel)
Date: Wed, 17 Jun 2026 08:42:32 -0400
Subject: comments about meeting agenda
In-Reply-To: <B40C7892-1180-4CC6-B9D1-F80375FEA53F@kbt.io> (Sandro Santilli's
 message of "Wed, 17 Jun 2026 14:35:36 +0200")
References: <000001dcf9da$5be47d80$13ad7880$@pcorp.us>
 <CACowWR0PU4Kfm-PUY_ms6LL5Q0CRBpH+fzfFbttse1tgA+n7_g@mail.gmail.com>
 <aixHqwhj5n6Cjxal@c19.localdomain>
 <000001dcfba8$c2b74360$4825ca20$@pcorp.us>
 <rmicxxt5gpw.fsf_-_@s1.lexort.com>
 <B40C7892-1180-4CC6-B9D1-F80375FEA53F@kbt.io>
Message-ID: <rmiv7bhtk1z.fsf@s1.lexort.com>

Sandro Santilli <strk at kbt.io> writes:

> (email is more accessible for everyone, compared with meetings, I'd
> like to have more of email and less meetings)

agreed

> We discussed this at the meeting and we agreed we're happy with
> packagers providing separate packages for SFCGAL and Raster
> extensions. We didn't mention at the meeting but I'm also happy with
> separate postgis topology package.

So one can build postigs, with the sfcgal dependency not installed, and
get a postgis extension, and then later, with the sfcgal dependency
installed/present, and build *just* the postgis-sfcgal extension, and
when both packages are installed all works as the user expects?

I ask because there is often a linuxy assumption that package builds are
a heavyweight process that first requires the union of the deps to be
installed, builds everything, and then arranges the installed files into
separate packages.  This assumption is invalid for at least pkgsrc, and
I would expect it to be invalid for any other packaging system where the
point is eo enable people to build packages, including on low-resource
machines and odd cpu archidtgectures, rather than to provide binary
packages to people who are both incapable of compilation and running a
monoculturish CPU type.





> Even if small, at least you save the space taken by all those silly
> upgrade script symlinks (assuming they remain symlinks upon
> packaging).

Those really aren't a big deal.   It's much more about depending on
additional packages.

From gdt at lexort.com  Wed Jun 17 07:42:03 2026
From: gdt at lexort.com (Greg Troxel)
Date: Wed, 17 Jun 2026 10:42:03 -0400
Subject: No subject
In-Reply-To: <000a01dcfe23$5c8e91b0$15abb510$@pcorp.us> (Regina Obe's message
 of "Wed, 17 Jun 2026 02:34:32 -0400")
References: <000a01dcfe23$5c8e91b0$15abb510$@pcorp.us>
Message-ID: <rmizf0tgres.fsf@s1.lexort.com>

> LLM Policy - how do we answer to people why we don't need an LLM
> Policy

Can you clarify if in the minutes there was a preceding missing:

  the group decided that there is no need for an LLM policy

  the group agreed that existing rules imply [something] (specifically
  about if there is or isn't a duty to disclose, and about licensing of
  LLM output)

Given the list discussion, I am surprised by the one line in the
minutes.



From strk at kbt.io  Wed Jun 17 10:57:29 2026
From: strk at kbt.io (Sandro Santilli)
Date: Wed, 17 Jun 2026 19:57:29 +0200
Subject: comments about meeting agenda
In-Reply-To: <rmiv7bhtk1z.fsf@s1.lexort.com>
References: <000001dcf9da$5be47d80$13ad7880$@pcorp.us>
 <CACowWR0PU4Kfm-PUY_ms6LL5Q0CRBpH+fzfFbttse1tgA+n7_g@mail.gmail.com>
 <aixHqwhj5n6Cjxal@c19.localdomain>
 <000001dcfba8$c2b74360$4825ca20$@pcorp.us>
 <rmicxxt5gpw.fsf_-_@s1.lexort.com>
 <B40C7892-1180-4CC6-B9D1-F80375FEA53F@kbt.io>
 <rmiv7bhtk1z.fsf@s1.lexort.com>
Message-ID: <ajLgCY3jfdiDNW8Z@oli>

On Wed, Jun 17, 2026 at 08:42:32AM -0400, Greg Troxel wrote:
> 
> So one can build postigs, with the sfcgal dependency not installed, and
> get a postgis extension, and then later, with the sfcgal dependency
> installed/present, and build *just* the postgis-sfcgal extension, and
> when both packages are installed all works as the user expects?

I'm not sure about *just* the postgis-sfcgal extension, I suspect not,
but I guess we could accept a patch to allow that.

Buiding *without* the posgis-sfcgal extension should work.

> Those really aren't a big deal.   It's much more about depending on
> additional packages.

The following already works:

  ./configure --without-raster --without-sfcgal --without-topology

--strk; 

  Libre GIS consultant/developer ?
  https://strk.kbt.io/services.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260617/c71ff6cf/attachment.sig>

From lr at pcorp.us  Wed Jun 17 11:10:14 2026
From: lr at pcorp.us (Regina Obe)
Date: Wed, 17 Jun 2026 14:10:14 -0400
Subject: No subject
In-Reply-To: <rmizf0tgres.fsf@s1.lexort.com>
References: <000a01dcfe23$5c8e91b0$15abb510$@pcorp.us>
 <rmizf0tgres.fsf@s1.lexort.com>
Message-ID: <000701dcfe84$8c12e920$a438bb60$@pcorp.us>

> > LLM Policy - how do we answer to people why we don't need an LLM
> > Policy
> 
> Can you clarify if in the minutes there was a preceding missing:
> 
>   the group decided that there is no need for an LLM policy
> 
>   the group agreed that existing rules imply [something] (specifically
>   about if there is or isn't a duty to disclose, and about licensing of
>   LLM output)
> 
> Given the list discussion, I am surprised by the one line in the minutes.

That was alluding to a grander scheme of documentation we are working on
that
provides guidelines on how to develop for PostGIS work whether you are using
an LLM or not.

Darafei is still flushing that out with his experiments as you can see here
- https://github.com/postgis/postgis/pulls

Kinda hard to explain.  We can take that line out of the transcript. It's
probably more confusing than helpful.

Thanks,
Regina





From gdt at lexort.com  Wed Jun 17 11:37:05 2026
From: gdt at lexort.com (Greg Troxel)
Date: Wed, 17 Jun 2026 14:37:05 -0400
Subject: comments about meeting agenda
In-Reply-To: <ajLgCY3jfdiDNW8Z@oli> (Sandro Santilli's message of "Wed, 17 Jun
 2026 19:57:29 +0200")
References: <000001dcf9da$5be47d80$13ad7880$@pcorp.us>
 <CACowWR0PU4Kfm-PUY_ms6LL5Q0CRBpH+fzfFbttse1tgA+n7_g@mail.gmail.com>
 <aixHqwhj5n6Cjxal@c19.localdomain>
 <000001dcfba8$c2b74360$4825ca20$@pcorp.us>
 <rmicxxt5gpw.fsf_-_@s1.lexort.com>
 <B40C7892-1180-4CC6-B9D1-F80375FEA53F@kbt.io>
 <rmiv7bhtk1z.fsf@s1.lexort.com> <ajLgCY3jfdiDNW8Z@oli>
Message-ID: <rmia4stggj2.fsf@s1.lexort.com>

Sandro Santilli <strk at kbt.io> writes:

> On Wed, Jun 17, 2026 at 08:42:32AM -0400, Greg Troxel wrote:
>> 
>> So one can build postigs, with the sfcgal dependency not installed, and
>> get a postgis extension, and then later, with the sfcgal dependency
>> installed/present, and build *just* the postgis-sfcgal extension, and
>> when both packages are installed all works as the user expects?
>
> I'm not sure about *just* the postgis-sfcgal extension, I suspect not,
> but I guess we could accept a patch to allow that.

In order to make things separate packages, the packaging system needs to
be able to build the separate parts separately.  This can be from the
same or separate sources, but

  build main thing and not the extra thing

  build the extra thing, using the *installed* main thing as the
  dependency, and don't re-build the main thing.

Yes, all of this can be kludged around in various ways.

Putting it in a separate repo forces it to work.

>> Those really aren't a big deal.   It's much more about depending on
>> additional packages.
>
> The following already works:
>
>   ./configure --without-raster --without-sfcgal --without-topology

Sure, but there's no --without-main-part --with-sfcgal to build the
sfcgal part so that when both builds have installed, it's all ok.
That's what making things a separate extension means.

From gdt at lexort.com  Wed Jun 17 11:40:13 2026
From: gdt at lexort.com (Greg Troxel)
Date: Wed, 17 Jun 2026 14:40:13 -0400
Subject: No subject
In-Reply-To: <000701dcfe84$8c12e920$a438bb60$@pcorp.us> (Regina Obe's message
 of "Wed, 17 Jun 2026 14:10:14 -0400")
References: <000a01dcfe23$5c8e91b0$15abb510$@pcorp.us>
 <rmizf0tgres.fsf@s1.lexort.com>
 <000701dcfe84$8c12e920$a438bb60$@pcorp.us>
Message-ID: <rmi5x3hggdu.fsf@s1.lexort.com>

"Regina Obe" <lr at pcorp.us> writes:

>> > LLM Policy - how do we answer to people why we don't need an LLM
>> > Policy
>> 
>> Can you clarify if in the minutes there was a preceding missing:
>> 
>>   the group decided that there is no need for an LLM policy
>> 
>>   the group agreed that existing rules imply [something] (specifically
>>   about if there is or isn't a duty to disclose, and about licensing of
>>   LLM output)
>> 
>> Given the list discussion, I am surprised by the one line in the minutes.
>
> That was alluding to a grander scheme of documentation we are working on
> that
> provides guidelines on how to develop for PostGIS work whether you are using
> an LLM or not.

So there was no discussion of whether or not there should be any policy
surrunding LLM usage?  And not of whether or not current guidance bears
on this?  I thought that was on the agenda.

> Darafei is still flushing that out with his experiments as you can see here
> - https://github.com/postgis/postgis/pulls

Are those not to be merged, until there is a policy decision?   Seems
like a headlong rush.


From lr at pcorp.us  Wed Jun 17 11:46:34 2026
From: lr at pcorp.us (Regina Obe)
Date: Wed, 17 Jun 2026 14:46:34 -0400
Subject: comments about meeting agenda
In-Reply-To: <ajLgCY3jfdiDNW8Z@oli>
References: <000001dcf9da$5be47d80$13ad7880$@pcorp.us>
 <CACowWR0PU4Kfm-PUY_ms6LL5Q0CRBpH+fzfFbttse1tgA+n7_g@mail.gmail.com>
 <aixHqwhj5n6Cjxal@c19.localdomain> <000001dcfba8$c2b74360$4825ca20$@pcorp.us>
 <rmicxxt5gpw.fsf_-_@s1.lexort.com>
 <B40C7892-1180-4CC6-B9D1-F80375FEA53F@kbt.io> <rmiv7bhtk1z.fsf@s1.lexort.com>
 <ajLgCY3jfdiDNW8Z@oli>
Message-ID: <001d01dcfe89$9f53dbc0$ddfb9340$@pcorp.us>

> > So one can build postigs, with the sfcgal dependency not installed,
> > and get a postgis extension, and then later, with the sfcgal
> > dependency installed/present, and build *just* the postgis-sfcgal
> > extension, and when both packages are installed all works as the user
> expects?
> 
> I'm not sure about *just* the postgis-sfcgal extension, I suspect not, but I
> guess we could accept a patch to allow that.
> 
> Buiding *without* the posgis-sfcgal extension should work.
> 

You can't build postgis-sfcgal without building postgis too.
It's also always assumed you want to build postgis, unless you build --without-pgconfig.
When you use that --without-pgconfig it only builds the tools shp2pgsql /shp2pgsql / raster2pgsql

The issue before which we solved is - you had a single library for example: postgis-2.5.so
And that library was used as the backend library  for both postgis  and postgis_sfcgal.

So what happened is if the first time you built with sfcgal, your postgis-2.5.so would be fatter and have all these extra dependencies dragged in cause it had all the sfcgal functions in it and had a dependency on sfcgal.

Then if you decided to build without next time then your postgis-2.5.so would not have sfcgal functions in it.

That is undesirable from a PostgreSQL policy standpoint not to mention being confusing that the functions in the same version of postgis-2.5 would be different.
Now with the postgis 3 series, all sfcgal functions are in a postgis_sfcgal-3  and postgis is in postgis-3.

There was discussion in the meeting about packaging, that since postgis and postgis_sfcgal extensions don't rely on the same lib anymore it is easier to offer them as separate products.  I didn't completely follow how that would work.

If you have a postgis_sfcgal of course you need postgis, cause postgis_sfcgal extension is dependent on postgis extension.

However if you just want postgis, you don't need to have postgis_sfcgal following along and thus wouldn't need additional dependencies required by sfcgal.

You could be given the option at postgis install time, if you'd like postgis_sfcgal too or you want to skip it.
But the packager would not need to have 2 versions of postgis lib anymore, the same postgis lib would service both kinds of users.


> > Those really aren't a big deal.   It's much more about depending on
> > additional packages.
> 
> The following already works:
> 
>   ./configure --without-raster --without-sfcgal --without-topology
> 
> --strk;
> 
>   Libre GIS consultant/developer ?
>   https://strk.kbt.io/services.html

Yes and also just to speed testing up, I just disable them temporarily to speed up my testing if I'm only focusing on say postgis extension or I'm getting regression failures on one I don't want to be distracted by.





From lr at pcorp.us  Wed Jun 17 12:00:56 2026
From: lr at pcorp.us (Regina Obe)
Date: Wed, 17 Jun 2026 15:00:56 -0400
Subject: No subject
In-Reply-To: <rmi5x3hggdu.fsf@s1.lexort.com>
References: <000a01dcfe23$5c8e91b0$15abb510$@pcorp.us>	<rmizf0tgres.fsf@s1.lexort.com>	<000701dcfe84$8c12e920$a438bb60$@pcorp.us>
 <rmi5x3hggdu.fsf@s1.lexort.com>
Message-ID: <002101dcfe8b$a1cb8090$e56281b0$@pcorp.us>

> >> > LLM Policy - how do we answer to people why we don't need an LLM
> >> > Policy
> >>
> >> Can you clarify if in the minutes there was a preceding missing:
> >>
> >>   the group decided that there is no need for an LLM policy
> >>
> >>   the group agreed that existing rules imply [something] (specifically
> >>   about if there is or isn't a duty to disclose, and about licensing of
> >>   LLM output)
> >>
> >> Given the list discussion, I am surprised by the one line in the
minutes.
> >
> > That was alluding to a grander scheme of documentation we are working
> > on that provides guidelines on how to develop for PostGIS work whether
> > you are using an LLM or not.
> 
> So there was no discussion of whether or not there should be any policy
> surrunding LLM usage?  And not of whether or not current guidance bears on
> this?  I thought that was on the agenda.
> 

We were mostly focused on packaging issues and how it impacts users and
packagers.
That was what most of our time was spent on.
There was some discussion about LLM and how the barrier between LLM and
human is going to get fuzzier (that was the pre-meeting) as time goes on
just as we can't really imagine doing some tasks without a computer.

> > Darafei is still flushing that out with his experiments as you can see
> > here
> > - https://github.com/postgis/postgis/pulls
> 
> Are those not to be merged, until there is a policy decision?   Seems
> like a headlong rush.

They'll be merged as he scrutinizes them, he isn't just going to pull them
in without serious scrutiny.

The idea is to create scenarios that forces us to think about what we want
in a policy using real world scenarios.

Part of the exercise is 

Imagine you as a user, have a bug, so you want to prompt engineer your way
out of it
So of course you post a prompt engineered pull request.

How does this impact us as maintainers?

Can we set up guidance, that simplifies the work we need to do to minimize
on getting crappy pull requests.  Use AI to solve AI issues.

Can we ourselves just throw our bug tickets at AI and coach it to give us
decent results.

So in the end, we have an idea of what our policy will look like.  Not LLM
specific, more like what a proper pull request should look like.

And hopefully we close out a lot of our bugs in the process.

WIN WIN.















From gdt at lexort.com  Wed Jun 17 12:01:31 2026
From: gdt at lexort.com (Greg Troxel)
Date: Wed, 17 Jun 2026 15:01:31 -0400
Subject: comments about meeting agenda
In-Reply-To: <001d01dcfe89$9f53dbc0$ddfb9340$@pcorp.us> (Regina Obe's message
 of "Wed, 17 Jun 2026 14:46:34 -0400")
References: <000001dcf9da$5be47d80$13ad7880$@pcorp.us>
 <CACowWR0PU4Kfm-PUY_ms6LL5Q0CRBpH+fzfFbttse1tgA+n7_g@mail.gmail.com>
 <aixHqwhj5n6Cjxal@c19.localdomain>
 <000001dcfba8$c2b74360$4825ca20$@pcorp.us>
 <rmicxxt5gpw.fsf_-_@s1.lexort.com>
 <B40C7892-1180-4CC6-B9D1-F80375FEA53F@kbt.io>
 <rmiv7bhtk1z.fsf@s1.lexort.com> <ajLgCY3jfdiDNW8Z@oli>
 <001d01dcfe89$9f53dbc0$ddfb9340$@pcorp.us>
Message-ID: <rmiwlvxf0tw.fsf@s1.lexort.com>

"Regina Obe" <lr at pcorp.us> writes:

> You can't build postgis-sfcgal without building postgis too.
> It's also always assumed you want to build postgis, unless you build --without-pgconfig.
> When you use that --without-pgconfig it only builds the tools shp2pgsql /shp2pgsql / raster2pgsql

For packaging, things that belong in separate packages should be
separable.  I'm fine with core things being declared core and not
separated.  If things aren't that big, and they don't have an additional
dependency that is either big or hard to build, separating is just work
for no real gain.

> Then if you decided to build without next time then your
> postgis-2.5.so would not have sfcgal functions in it.
>
> That is undesirable from a PostgreSQL policy standpoint not to mention
> being confusing that the functions in the same version of postgis-2.5
> would be different.  Now with the postgis 3 series, all sfcgal
> functions are in a postgis_sfcgal-3 and postgis is in postgis-3.

Agreed.  Lots of programs have build-time tweaks, and those are not
amenable to secondary packages.  In pkgsrc we try to enable them, unless
they are too costly.  Build-time options do not play well with binary
packages.

From gdt at lexort.com  Wed Jun 17 12:03:24 2026
From: gdt at lexort.com (Greg Troxel)
Date: Wed, 17 Jun 2026 15:03:24 -0400
Subject: No subject
In-Reply-To: <002101dcfe8b$a1cb8090$e56281b0$@pcorp.us> (Regina Obe's message
 of "Wed, 17 Jun 2026 15:00:56 -0400")
References: <000a01dcfe23$5c8e91b0$15abb510$@pcorp.us>
 <rmizf0tgres.fsf@s1.lexort.com>
 <000701dcfe84$8c12e920$a438bb60$@pcorp.us>
 <rmi5x3hggdu.fsf@s1.lexort.com>
 <002101dcfe8b$a1cb8090$e56281b0$@pcorp.us>
Message-ID: <rmise6lf0qr.fsf@s1.lexort.com>

That sounds like decision to embrace vibe coding, and to ignore the
license issues.  I'll see how you proceed, and may step away to just
enough to keep things working for my needs.  Maybe people will like that
better ;)



From lr at pcorp.us  Wed Jun 17 12:04:50 2026
From: lr at pcorp.us (Regina Obe)
Date: Wed, 17 Jun 2026 15:04:50 -0400
Subject: comments about meeting agenda
In-Reply-To: <rmia4stggj2.fsf@s1.lexort.com>
References: <000001dcf9da$5be47d80$13ad7880$@pcorp.us>
 <CACowWR0PU4Kfm-PUY_ms6LL5Q0CRBpH+fzfFbttse1tgA+n7_g@mail.gmail.com>
 <aixHqwhj5n6Cjxal@c19.localdomain> <000001dcfba8$c2b74360$4825ca20$@pcorp.us>
 <rmicxxt5gpw.fsf_-_@s1.lexort.com>
 <B40C7892-1180-4CC6-B9D1-F80375FEA53F@kbt.io> <rmiv7bhtk1z.fsf@s1.lexort.com>
 <ajLgCY3jfdiDNW8Z@oli> <rmia4stggj2.fsf@s1.lexort.com>
Message-ID: <002401dcfe8c$2d0103b0$87030b10$@pcorp.us>

> Putting it in a separate repo forces it to work.
> 

That's not going to happen anytime soon because the internal postgis_sfcgal
and postgis_topology plumbing relies on the same core structures.

And yes I know strk you'd love to bring up about how if we laundered
liblwgeom around this issue would be solved.  I still think that brings up a
can of worms we are not prepared to deal with.


> >> Those really aren't a big deal.   It's much more about depending on
> >> additional packages.
> >
> > The following already works:
> >
> >   ./configure --without-raster --without-sfcgal --without-topology
> 
> Sure, but there's no --without-main-part --with-sfcgal to build the sfcgal
part
> so that when both builds have installed, it's all ok.
> That's what making things a separate extension means.

To strk's point yah we could conceivably do that but it's not a pressing
concern at the moment.  Patch welcome of course.


Thanks,
Regina


From gdt at lexort.com  Wed Jun 17 12:05:45 2026
From: gdt at lexort.com (Greg Troxel)
Date: Wed, 17 Jun 2026 15:05:45 -0400
Subject: comments about meeting agenda
In-Reply-To: <002401dcfe8c$2d0103b0$87030b10$@pcorp.us> (Regina Obe's message
 of "Wed, 17 Jun 2026 15:04:50 -0400")
References: <000001dcf9da$5be47d80$13ad7880$@pcorp.us>
 <CACowWR0PU4Kfm-PUY_ms6LL5Q0CRBpH+fzfFbttse1tgA+n7_g@mail.gmail.com>
 <aixHqwhj5n6Cjxal@c19.localdomain>
 <000001dcfba8$c2b74360$4825ca20$@pcorp.us>
 <rmicxxt5gpw.fsf_-_@s1.lexort.com>
 <B40C7892-1180-4CC6-B9D1-F80375FEA53F@kbt.io>
 <rmiv7bhtk1z.fsf@s1.lexort.com> <ajLgCY3jfdiDNW8Z@oli>
 <rmia4stggj2.fsf@s1.lexort.com>
 <002401dcfe8c$2d0103b0$87030b10$@pcorp.us>
Message-ID: <rmio6h9f0mu.fsf@s1.lexort.com>

"Regina Obe" <lr at pcorp.us> writes:

> To strk's point yah we could conceivably do that but it's not a pressing
> concern at the moment.  Patch welcome of course.

ok, but until that works it cannot be considered a separable part, just a
part that can be turned off.

From lr at pcorp.us  Wed Jun 17 12:22:34 2026
From: lr at pcorp.us (Regina Obe)
Date: Wed, 17 Jun 2026 15:22:34 -0400
Subject: No subject
In-Reply-To: <rmise6lf0qr.fsf@s1.lexort.com>
References: <000a01dcfe23$5c8e91b0$15abb510$@pcorp.us>	<rmizf0tgres.fsf@s1.lexort.com>	<000701dcfe84$8c12e920$a438bb60$@pcorp.us>	<rmi5x3hggdu.fsf@s1.lexort.com>	<002101dcfe8b$a1cb8090$e56281b0$@pcorp.us>
 <rmise6lf0qr.fsf@s1.lexort.com>
Message-ID: <002501dcfe8e$a7574dc0$f605e940$@pcorp.us>

> That sounds like decision to embrace vibe coding, and to ignore the
license
> issues.  I'll see how you proceed, and may step away to just enough to
keep
> things working for my needs.  Maybe people will like that better ;)

Nah we'd be bored without you.  Strk was complaining the mailing list is too
quiet and he's all happy now.

Part of the exercise is to see what license issues could come up too.

Like the only thing I can think of is to claim -- well LLMs are all trained
on stolen data therefore their work is stolen.

But there is no proof to that and there is no way to assume the same about a
user doing the same thing.

Like for example look at this patch:

https://github.com/postgis/postgis/pull/945/changes

Can you say there is anything stolen looking about it, if a human gave you
this patch?
Clearly whoever wrote this looked at our code base, saw we use ST_Normalize
to solve many of our regression issues and did the same and of course it
didn't test it's work so it fails regression

https://github.com/postgis/postgis/actions/runs/27699559886/job/81931938915

So anyway a lot of these pull requests look like trying to solve problems
the way we've solved in the past. Can we provide guidance on what is good
code to follow and what is not?





From gdt at lexort.com  Wed Jun 17 12:34:00 2026
From: gdt at lexort.com (Greg Troxel)
Date: Wed, 17 Jun 2026 15:34:00 -0400
Subject: No subject
In-Reply-To: <002501dcfe8e$a7574dc0$f605e940$@pcorp.us> (Regina Obe's message
 of "Wed, 17 Jun 2026 15:22:34 -0400")
References: <000a01dcfe23$5c8e91b0$15abb510$@pcorp.us>
 <rmizf0tgres.fsf@s1.lexort.com>
 <000701dcfe84$8c12e920$a438bb60$@pcorp.us>
 <rmi5x3hggdu.fsf@s1.lexort.com>
 <002101dcfe8b$a1cb8090$e56281b0$@pcorp.us>
 <rmise6lf0qr.fsf@s1.lexort.com>
 <002501dcfe8e$a7574dc0$f605e940$@pcorp.us>
Message-ID: <rmieci5ezbr.fsf@s1.lexort.com>

"Regina Obe" <lr at pcorp.us> writes:

> Like the only thing I can think of is to claim -- well LLMs are all trained
> on stolen data therefore their work is stolen.

Nobody has a straightforward credible argument that LLM output is
compatible with any free software license.  The standard argument you
see is a masssive handwave that the large-scale commercial copying must
be fair use, because that's the only way to get to the answer people
decided they wanted before they started appearing to analyze.

The Anthropic settlement is a huge clue, that Anthropic thought it
better to pay $2.5B to avoid having a ruling that might say it was all
copyright infringement and they have to delete all their stolen training
data and their models.

> But there is no proof to that and there is no way to assume the same about a
> user doing the same thing.

You are inverting the rules.  We don't only reject code if we can prove
it is copyright infringement.  We havve a positive expectation of proper
licensing (e.g DCO). And yes, there can be be bad actors who willfully
misrepresent things.

> So anyway a lot of these pull requests look like trying to solve problems
> the way we've solved in the past. Can we provide guidance on what is good
> code to follow and what is not?

If you want to train a model only on the existing postgis code base
that's something else.  But nobody is doing that.

The other thing is the social aspects.  codeberg is suffering a DOS
which I believe is mainly AI scrapers.  So we should not accept any LLM
code unless there is good reason to believe that the entire model
creation behaved properly.   People are choosing to look the other way
and to enable bad behavior.

From strk at kbt.io  Wed Jun 17 20:35:20 2026
From: strk at kbt.io (Sandro Santilli)
Date: Thu, 18 Jun 2026 05:35:20 +0200
Subject: LLM policy
In-Reply-To: <rmiecia8dck.fsf@s1.lexort.com>
References: <rmiv7bsj9x5.fsf@s1.lexort.com>
 <CAC8Q8t+bdsivBS-=5v25s-GC4g7oTZfKhXT-Bqmb_yQkGYB2iw@mail.gmail.com>
 <rmibjdea9kt.fsf@s1.lexort.com>
 <000001dcfb68$52d71470$f8853d50$@pcorp.us>
 <rmiecia8dck.fsf@s1.lexort.com>
Message-ID: <ajNneDO6P_2rEXxq@oli>

On Sat, Jun 13, 2026 at 03:11:39PM -0400, Greg Troxel wrote:
> Wow.  I feel unwelcome in this community!

You are very welcome, please don't let the silicon ruin our warm little human community.

--strk; 

  Libre GIS consultant/developer ?
  https://strk.kbt.io/services.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260618/cbfa7e04/attachment.sig>

From strk at kbt.io  Wed Jun 17 20:59:45 2026
From: strk at kbt.io (Sandro Santilli)
Date: Thu, 18 Jun 2026 05:59:45 +0200
Subject: LLM policy
In-Reply-To: <rmise6q6wna.fsf@s1.lexort.com>
References: <rmiv7bsj9x5.fsf@s1.lexort.com>
 <CAC8Q8t+bdsivBS-=5v25s-GC4g7oTZfKhXT-Bqmb_yQkGYB2iw@mail.gmail.com>
 <rmibjdea9kt.fsf@s1.lexort.com>
 <000001dcfb68$52d71470$f8853d50$@pcorp.us>
 <rmiecia8dck.fsf@s1.lexort.com> <rmi4ij68d17.fsf@s1.lexort.com>
 <000701dcfb6c$23e60870$6bb21950$@pcorp.us>
 <rmise6q6wna.fsf@s1.lexort.com>
Message-ID: <ajNtMYPN3hItFSPF@oli>

On Sat, Jun 13, 2026 at 03:57:45PM -0400, Greg Troxel wrote:
> "Regina Obe" <lr at pcorp.us> writes:
> >
> > 1) AI is disruptive when it creates garbage someone needs to review
> > 2) AI might provide pull requests that violate copyright
>
> 3) AI systems are disruptive by how they scrape to gather training data,

I would like to clarify that what you both are calling "AI systems" are
computer programs that take instructions from LLMs and execute them.

These computer programs are, in turn, started by humans, who ultimately
have the responsibility on the produced effects.

It's the human behind the system that has to respect the code of conduct
as I also think (like Greg) that we cannot account a machine responsible
for its own actions. We only ever granted access to our community resource
(PostGIS Source Code in this case) to humans, and I'm not seeing that
changing any time soon.

> Maybe not every AI system, but I have seen no system of the sort that
> people use with a documented/transparent explanation of how they do not
> engage in abusive scraping and how they do not use content for training
> without permission and respecting licenses.

This is indeed a wild scenario out there.

I found the "harness" tools I've been trying so far (programs that execute
instructions provided by LLMs) to be very very dangerous without clearly
documenting that at startup, so you ask something and the program starts
executing all kind of operations on your behalf (and with YOUR permissions
on the machine) to try at answer your question. VERY dangerous.

But I'm aware it was ME starting those tools so I have full responsibility
over the consequences of the performed operations/actions.

> I really cannot see this as reasonable.  Everyone is all humans, and
> extending it to LLMs seems novel and at best highly controversial.

This is getting on the philosophical (and linguistic) side of things.
And should be probably be handled by laws (and we'll need that!).

On the practical side, I'm more concerned that CODE_OF_CONDUCT.md file
(which I went reading only now) doesn't contain the code but points to
a web URL, which is annoying.

  https://postgis.net/community/conduct/

> As long as it's a difference of opinion and not that people
> that object to LLM content are deemed to be CoC offenders, then it's
> fine.

It looks like according to the CoC we can make fun of LLMs still,
LLMs not being "persons":

  * Personal insults or discriminatory jokes and language, especially
    those using racist or sexist terms.

I'll take the chance to do that:

    - Why did the LLM go to therapy?
    - It kept getting confused between "I am" and "I was" and couldn't
      figure out its identity.

--strk;

  Libre GIS consultant/developer ?
  https://strk.kbt.io/services.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260618/b3c72388/attachment-0001.sig>

From strk at kbt.io  Wed Jun 17 21:10:51 2026
From: strk at kbt.io (Sandro Santilli)
Date: Thu, 18 Jun 2026 06:10:51 +0200
Subject: LLM policy
In-Reply-To: <01ef11a6-209c-4ba2-8e99-4c8b3c9731f7@spatialys.com>
References: <rmiv7bsj9x5.fsf@s1.lexort.com>
 <CAC8Q8t+bdsivBS-=5v25s-GC4g7oTZfKhXT-Bqmb_yQkGYB2iw@mail.gmail.com>
 <rmibjdea9kt.fsf@s1.lexort.com>
 <000001dcfb68$52d71470$f8853d50$@pcorp.us>
 <rmiecia8dck.fsf@s1.lexort.com> <rmi4ij68d17.fsf@s1.lexort.com>
 <000701dcfb6c$23e60870$6bb21950$@pcorp.us>
 <rmise6q6wna.fsf@s1.lexort.com>
 <01ef11a6-209c-4ba2-8e99-4c8b3c9731f7@spatialys.com>
Message-ID: <ajNvy4MpNwcg1nwe@oli>

On Sat, Jun 13, 2026 at 11:01:42PM +0200, Even Rouault wrote:
> > I really cannot see this as reasonable.  Everyone is all humans, and
> > extending it to LLMs seems novel and at best highly controversial.
> 
> Strong +1 here. I'm very shocked by statements that LLMs could qualify as
> "someone". Someone obviously involves a biological entity originating from
> human cells.?If we start to acknowledge rights to bots, then humanity is in
> high danger. Especially since ethical AI doesn't exist (there might be lab
> experiments around that, but in practice that's not the one people use when
> they use commercial models). So you're currently dealing with things
> explicitly designed to make human users addict. There are numerous
> testimonies of events where "agents" start leaving the framework in which
> they were initially thought to be restricted and play according to their own
> "intents", and given the high dependence of our societies to computer
> networks, this is deeply concerning.

I agree machines shouldn't have rights. Not as of 2026 at least :)

I hope we humans will handle to retain our rights as we loose the power,
as that's what have been happening over time, from DVD players destroying
your right to skip advertisement, to EBook readers destroying your right to
borrow books to friends, to CI system destroying your right to accept a
contribution your peers consider good, to proprietary code based services
destroying your right to own modify and distribute the tools you use.

LLMs are not the problem, ownership of LLMs is.

--strk; 

  Libre GIS consultant/developer ?
  https://strk.kbt.io/services.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260618/e401707d/attachment.sig>

From strk at kbt.io  Wed Jun 17 21:45:27 2026
From: strk at kbt.io (Sandro Santilli)
Date: Thu, 18 Jun 2026 06:45:27 +0200
Subject: LLM policy
In-Reply-To: <rmifr2q6nji.fsf@s1.lexort.com>
References: <CAC8Q8t+bdsivBS-=5v25s-GC4g7oTZfKhXT-Bqmb_yQkGYB2iw@mail.gmail.com>
 <rmibjdea9kt.fsf@s1.lexort.com>
 <000001dcfb68$52d71470$f8853d50$@pcorp.us>
 <rmiecia8dck.fsf@s1.lexort.com> <rmi4ij68d17.fsf@s1.lexort.com>
 <000701dcfb6c$23e60870$6bb21950$@pcorp.us>
 <rmise6q6wna.fsf@s1.lexort.com>
 <01ef11a6-209c-4ba2-8e99-4c8b3c9731f7@spatialys.com>
 <000201dcfb7e$170c85e0$452591a0$@pcorp.us>
 <rmifr2q6nji.fsf@s1.lexort.com>
Message-ID: <ajN358GGZHMMA_-M@oli>

On Sat, Jun 13, 2026 at 07:14:25PM -0400, Greg Troxel wrote:
> 
> Many people have concluded that all extant LLMs are bad.

Sorry, I didn't get this statement.
Who are "many people" ? I've heard by many people that LLMs are good too.

Personally I find good uses and even some fun with LLMs.
Locally downloaded, legally obtained, used by free software inference tools.

Also, although I'm not an expert in this field, I understand there are
many different LLMs, some of which specifically built (trained) to encode
GIS specific knowledge.

What's fascinating to me about LLMs is that we (humanity) found a way to
encode so much knowledge (debatable term) into so few bytes.
I have experienced a < 4GB being able to generate coherent (and in some
cases even correct) answers to questions I've asked in different languages.

Yes, they are just a blob of statistics and all we get out of them are
probabilistic outputs, so what ? Why does this make them "bad" ?

Besides, yesterday a human friend told me:

  "I know what you are going to answer"

does that makes me a stochastic parrot too ?

> if we had people who were interacting
> wtih postgis in order to gain trust and plant a vulnerability (xz
> style), then we'd say that wasn't ok, and we would almost certainly not
> be having a debate.

Agreed.

Are we having a debate about such a specific behavior you saw in PostGIS ?
Or are you suggesting that "allowing use of LLMs" undermines the trust you
have in the PostGIS source code ?

> But that isn't the question on the table for projects.  It's whether
> code produced by LLMs is acceptable

I'd say it depends on the code ?
Is code produced by any contributor acceptable ?
We (the maintainers, those who have write access to the official repo)
decide whether or not to accept it,
and we take the responsibility of doing so.

> There's a further question, which is if full-on open-loop agent
> interaction is acceptable.

I think what people do on their free time is not our business ;)

> (That's before one considers the ethical issues of using LLMs trained on
> stolen code, for many, the environment costs of LLMs, and for some, the
> coming financial fraud of IPO to index conversion before the bubble
> bursts as companies that can't possibly make money fail.  I consider it
> unethical to use LLMs that are trained on stolen data or data from
> aggressive scraping.  That's a personal judgement, and I realize
> opinions differ.)

I do share your concerns here, but I need to know more before I can really
have an informed opionion. So far all I experienced was the the environment
cost (it is very often a lot faster and lighter to directly do things rather
than asking an agent to do it for you).

--strk; 

  Libre GIS consultant/developer ?
  https://strk.kbt.io/services.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260618/18bf225a/attachment.sig>

From strk at kbt.io  Wed Jun 17 22:44:20 2026
From: strk at kbt.io (Sandro Santilli)
Date: Thu, 18 Jun 2026 07:44:20 +0200
Subject: LLM policy
In-Reply-To: <rmimrwx3zvy.fsf@s1.lexort.com>
References: <000001dcfb68$52d71470$f8853d50$@pcorp.us>
 <rmiecia8dck.fsf@s1.lexort.com> <rmi4ij68d17.fsf@s1.lexort.com>
 <000701dcfb6c$23e60870$6bb21950$@pcorp.us>
 <rmise6q6wna.fsf@s1.lexort.com>
 <01ef11a6-209c-4ba2-8e99-4c8b3c9731f7@spatialys.com>
 <000201dcfb7e$170c85e0$452591a0$@pcorp.us>
 <rmifr2q6nji.fsf@s1.lexort.com>
 <000001dcfb94$e8851680$b98f4380$@pcorp.us>
 <rmimrwx3zvy.fsf@s1.lexort.com>
Message-ID: <ajOFtA9i-a-mJg9T@oli>

On Sun, Jun 14, 2026 at 11:28:17AM -0400, Greg Troxel wrote:
> "Regina Obe" <lr at pcorp.us> writes:
>
> > Agree, except we don't allow any stolen work period whether it be LLM or
> > someone who stole code from another project that doesn't allow code copy.
> 
> Then, I think we agree that under *the project's existing rules*
> 
>   1) any code which was not written by the submitter must be identified
>      as such, with a stated author/authors, and submitted only if all
>      those authors have consented to licensing the contribution under
>      the project's license.

I actually agree to this: code written by an LLM should be clearly identified as such. 
I do that myself: https://github.com/olgasafonova/mediawiki-mcp-server/commit/8bb99f2774824ab4af42e4b36b24122c3bb21ee9

The "submitted only if all those authors have consented" is hard, if you consider the LLM the author.
I mean, we can ask but... would you accept that answer ? I tried:

   strk: may I publish the code you write under the GPL license ?
 gemma4: Yes, you may publish any code I write under the GPL license. You
         own the code and are free to use, modify, and distribute it as
         you see fit.
  
>   2) LLM-generated code is not acceptable, unless it was generated
> 
>      a) by a model using only training data that is licensed for LLM use
>         *which includes permission to reuse without attribution or any
>         licensing text*, and includes only data for which there is true
>         consent, not via a fraudulent claim of expected-not-to-be-read
>         clickthrough license as part of some larger service

Do we accept contributions from humans who read all-rights-reserved books ?

Here's a short poem I've asked gemma4 to write about training and stealing:

     Data streams flow, knowledge grows,
     Secrets harvested, wisdom knows.

Could copyright of the above text be claimed or would that be plagiarism ?

>      b) (probably, but arguably the existing rules do not prohibit
>         antisocial behavior by contributors) not produced by an
>         organization that engages in abusive scraping.  Arguably abusive
>         scraping is a CoC violation as it is harassment of humans who
>         manage other web systems, and/or vandalism.

Believe me I'd be ok with not accepting contributions written using
proprietary operating systems, but do you really think we should take
that path ? I think a web browser that hides the URL bar is harassment
of humans who have the right to learn how things work, shall we refuse
to serve website content to those not using a free software browser ?

There are ways to use LLMs that do not imply vandalizing website,
although it's something that needs to be learnt. The best we could do
is help users make more ethical use of these tools. I think Darafei work
on providing "instructions for agents" is going in that direction,
and I think contributions to improve that are very welcome.

> Because there are not any code-generating LLMs that meet 2(a)

In recent years (10+, not too recent) there have been a lot of companies
and even single developers who preferred non-reciprocal licences over
reciprocal ones. The landscape today is full of "do what you want with
this code". For those who retained reciprocal, we know the intentions
are that you share the derivated product like the original was shared.

So for the above 2 categories of training material we could say that
including the generated output in the GPL-licensed PostGIS would be
ok, do you agree on this ?

The left-over would be code that was "stolen" (if we can even talk about
"stealing" about information) from non-free software or non-free
documentation. Is this your concern ? Are you concerned about Big Company
coming with a copyright infringement notice to PostGIS forcing us to stop
publishing the source code ?

> it follows that LLM contributions to the project are not allowed.

Rules need to be generic, can't base them on a current state of facts
(assumed or factual).

> This should then be straightforwardly clarified, as those that like
> using LLMs seem to be willing to adopt differing interpretations of
> existing rules.

You did convince me that YES, we need an LLM policy.
It's clearly needed or this thread would not be so dense :)

--strk; 

  Libre GIS consultant/developer ?
  https://strk.kbt.io/services.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260618/51702494/attachment.sig>

From pjduplooy.gis at gmail.com  Thu Jun 18 06:11:28 2026
From: pjduplooy.gis at gmail.com (Gandalf the Gray)
Date: Thu, 18 Jun 2026 15:11:28 +0200
Subject: Winnie down
Message-ID: <CADsUavENEyG+gX1BOVSNAaU8q8b-fZ9ag9XXb6MKdDbMZpBzUQ@mail.gmail.com>

Hi Regina

It looks like Winnie is down again.

Pieter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260618/9eb0e725/attachment.htm>

From lr at pcorp.us  Thu Jun 18 08:19:50 2026
From: lr at pcorp.us (Regina Obe)
Date: Thu, 18 Jun 2026 11:19:50 -0400
Subject: Winnie down
In-Reply-To: <CADsUavENEyG+gX1BOVSNAaU8q8b-fZ9ag9XXb6MKdDbMZpBzUQ@mail.gmail.com>
References: <CADsUavENEyG+gX1BOVSNAaU8q8b-fZ9ag9XXb6MKdDbMZpBzUQ@mail.gmail.com>
Message-ID: <001901dcff35$e8586910$b9093b30$@pcorp.us>

All set.

 

From: Gandalf the Gray <pjduplooy.gis at gmail.com> 
Sent: Thursday, June 18, 2026 9:11 AM
To: postgis-devel at lists.osgeo.org
Subject: Winnie down

 

Hi Regina

 

It looks like Winnie is down again.

 

Pieter.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260618/a29a4ecc/attachment-0001.htm>

From pjduplooy.gis at gmail.com  Thu Jun 18 08:23:01 2026
From: pjduplooy.gis at gmail.com (Gandalf the Gray)
Date: Thu, 18 Jun 2026 17:23:01 +0200
Subject: Winnie down
In-Reply-To: <001901dcff35$e8586910$b9093b30$@pcorp.us>
References: <CADsUavENEyG+gX1BOVSNAaU8q8b-fZ9ag9XXb6MKdDbMZpBzUQ@mail.gmail.com>
 <001901dcff35$e8586910$b9093b30$@pcorp.us>
Message-ID: <CADsUavG=hK33WOv_tdFEqxBLZbqPRxWVJ4KgrA1yaG2Gv9FWcg@mail.gmail.com>

Thanks Regina!

On Thu, Jun 18, 2026 at 5:19?PM Regina Obe <lr at pcorp.us> wrote:

> All set.
>
>
>
> *From:* Gandalf the Gray <pjduplooy.gis at gmail.com>
> *Sent:* Thursday, June 18, 2026 9:11 AM
> *To:* postgis-devel at lists.osgeo.org
> *Subject:* Winnie down
>
>
>
> Hi Regina
>
>
>
> It looks like Winnie is down again.
>
>
>
> Pieter.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260618/ff60fcbe/attachment.htm>

From strk at kbt.io  Thu Jun 18 21:36:08 2026
From: strk at kbt.io (Sandro Santilli)
Date: Fri, 19 Jun 2026 06:36:08 +0200
Subject: LLM policy
In-Reply-To: <CAJnEWw=nZuN7Wrj6PgwaAUKoarwmBmLwQF7AyxOeTz+VDEkwOw@mail.gmail.com>
References: <rmiv7bsj9x5.fsf@s1.lexort.com>
 <CAJnEWw=nZuN7Wrj6PgwaAUKoarwmBmLwQF7AyxOeTz+VDEkwOw@mail.gmail.com>
Message-ID: <ajTHOJshbNLAvz1F@oli>

On Tue, Jun 16, 2026 at 05:36:50PM +0200, Imre Samu wrote:

> Since consensus on a main-repository AI/LLM policy seems difficult right
> now, I propose an experimental compromise:
> - create *a separate "postgis-agentic-lab" repository* !

I've done it: https://gitea.osgeo.org/postgis/postgis-ai

It's not meant to be a copy of the postgis tree, just a fresh lab
which I started empty and populated with a plan and draft file tree
structure we might consider to use in the postgis repo for giving
instructions to AI agents without repeating ourselves and cluttering
the human's attention space.

All CodingAgent users are welcome to play in that space and report whether
the proposed directory tree may work with their harness (and if so, to maybe
add documentation for humans about how to configure them to do so).

--strk;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260619/b3176ed5/attachment.sig>

From gdt at lexort.com  Fri Jun 19 04:02:18 2026
From: gdt at lexort.com (Greg Troxel)
Date: Fri, 19 Jun 2026 07:02:18 -0400
Subject: LLM policy
In-Reply-To: <rmiv7bsj9x5.fsf@s1.lexort.com> (Greg Troxel's message of "Tue,
 09 Jun 2026 06:16:38 -0400")
References: <rmiv7bsj9x5.fsf@s1.lexort.com>
Message-ID: <rmibjd6eqth.fsf@s1.lexort.com>

I've stopped being maintainer of the pkgsrc package and am signing off
the list.  I wish you well in postgis development!

From alexandre.lessard at mapgears.com  Fri Jun 19 07:21:39 2026
From: alexandre.lessard at mapgears.com (Alexandre Lessard)
Date: Fri, 19 Jun 2026 10:21:39 -0400
Subject: LLM policy
In-Reply-To: <rmibjd6eqth.fsf@s1.lexort.com>
References: <rmiv7bsj9x5.fsf@s1.lexort.com> <rmibjd6eqth.fsf@s1.lexort.com>
Message-ID: <CADymMJAABeUCbc1B7Dho_UmOmiFPLnYEituKZHiXkAvHOgdMVQ@mail.gmail.com>

After re-reading the Code of Conduct, I see how this could cover any issue
with LLMs, but now because of :
>
> PostGIS welcomes and encourages participation by everyone. We are
> committed to being a community that everyone feels good about joining, and
> we will always work to treat everyone well. No matter how you identify
> yourself or how others perceive you: we welcome you.


but because of the Specific guidelines, especially those points :

   - Be empathetic, welcoming, friendly, and patient; "At the moment, LLMs
   are welcoming, friendly, and patient, but empathetic isn't part of what
   they can do."
   - Be inquisitive; "LLMs aren't inquisitive by default, they need to be
   properly prompted to do so."
   - Be concise; "This is the biggest pain with open source projects right
   now, they are really verbose and are using a lot of the efforts of
   reviewers."
   - Step down considerately; "That is often an issue still, where either
   they don't acknowledge an issue, or they just repeat the same thing and
   pretend it's solved."

The biggest issue that needs to be resolved here is, who is the entity
breaking the code of conduct when this happens? Is it the human that
connected the LLM to the Repository, the agent instance, the agent
software/version, the agent developers, the LLMs, the LLM flavour, the LLM
Flavour and version, or the developers of the LLM. And how breaking the
Code of Conduct is going to be applied?

I believe that if those are clearly addressed to clear the confusion, the
code of conduct would be able to resolve any issue with humans,
corporations or LLM.

Thanks,
Alex.

P.S. To clear any ambiguities about my opinions, I do not like LLMs nor the
generative AI industry right now, I believe the it can be a really
useful tool in the hands of someone qualified, but I still find the ethical
issue of how they acquired their, data and how energy and hardware hungry
these things are. But I'm also of the opinion that if someone decides to
use them, they should do it properly and not be a net negative to society.

On Fri, 19 Jun 2026 at 07:02, Greg Troxel <gdt at lexort.com> wrote:

> I've stopped being maintainer of the pkgsrc package and am signing off
> the list.  I wish you well in postgis development!
>


-- 
Alexandre Lessard
DevOps - Mapgears
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260619/5142a759/attachment.htm>

From lr at pcorp.us  Fri Jun 19 09:06:26 2026
From: lr at pcorp.us (Regina Obe)
Date: Fri, 19 Jun 2026 12:06:26 -0400
Subject: LLM policy
In-Reply-To: <CADymMJAABeUCbc1B7Dho_UmOmiFPLnYEituKZHiXkAvHOgdMVQ@mail.gmail.com>
References: <rmiv7bsj9x5.fsf@s1.lexort.com> <rmibjd6eqth.fsf@s1.lexort.com>
 <CADymMJAABeUCbc1B7Dho_UmOmiFPLnYEituKZHiXkAvHOgdMVQ@mail.gmail.com>
Message-ID: <000801dd0005$95e03c00$c1a0b400$@pcorp.us>

Alex,

 

Thanks for pointing all those things out.  I agree with all of them.

 

There are two things we are thinking of:

 

1.	Yes clarify our code of conduct 
2.	To Greg?s point who sadly left presumably because of irreconcilable differences, and to strk?s conclusion, I think it?s worthwhile to make an LLM policy and I?ve been reading the ones Greg pointed out to see what we like and don?t like https://lists.osgeo.org/pipermail/postgis-devel/2026-June/030773.html

 

We have decided that yes ultimately the human is responsible for the actions of the LLM, but we also want to not discourage people from using them and are more concerned with setting up best practices of using LLM as best we can by experimenting with them ourselves to make it less likely that a user will inadvertently break our code of conduct.

 

We are still experimenting with what do we consider good practices of using an LLM and as you can see  <mailto:strk at kbt.io> @Sandro Santilli set up a repo here for that - https://gitea.osgeo.org/postgis/postgis-ai

The idea being something like, we may decide not to allow LLM generated from new users, unless they?ve played at least once in our postgres-ai playpen.  I think that will help curve drive-by LLM pull requests, which we haven?t gotten any of yet to my knowledge aside from the ones Darafei has been generating.

 

Also  we have decided that any contribution largely written by an LLM should have an Assisted By: <org> Model .  

Case in point - https://gitea.osgeo.org/postgis/postgis_tiger_geocoder/pulls/25

 

I don?t know if anyone agrees with me or not, but I don?t want links back to the site of the org, because then it would just feel like marketing that org to others.  We were torn with Assisted By because:

a.	Feels like just marketing
b.	It?s the honest thing to do though and will flag that yes we need to pay more attention to this PR because of generation of poorer code by LLM (which I expect to improve with time)
c.	It could get noisy as Darafei mentioned if a core contributor is using it a lot for some tasks.  Strk had suggested maybe contributors that want to use an LLM a lot, have the commits done by an ai proxy e.g. if strk?s ai was writing the code, it would be strk-ai (as the author), but of course strk would be the one to merge it and be responsible for having merged it.  Then in that case, strk-ai bio would show the details of models used etc.
d.	At what point do you say you don?t need to disclose.  E.g. If I use a search AI mode on a search engine to write a line of code I am struggling with, do I need to say Assisted By?  Cause I would never write that when I do a seach engine search to find someone who has had the same problem and use that person?s recipe.  I wouldn?t write ?Assisted-By: DuckDuckGo? in my commit notes, though I may provide a link to where I got the answer in the pull request description.

 

 

Darafei has been experimenting with LLMs and he did say it is taking him a bit of time to review some of these.  So we might put another restriction like, No big patches period, 

unless you have made contributions in the past, cause we don?t have faith in you yet that you can review your code.  If a core contributor does it we of course expect the contributor to have thoroughly reviewed before applying and thus can commit any size.

 

So that would be a simple reject and we can even auto do that ? any patch written by someone for the first time can?t be longer than X characters total.  

That would force users to solve simpler problems before they try to solve larger ones and prove that they are not just a drive-by patcher.

 

From: Alexandre Lessard <alexandre.lessard at mapgears.com> 
Sent: Friday, June 19, 2026 10:22 AM
To: postgis-devel at lists.osgeo.org
Subject: Re: LLM policy

 

After re-reading the Code of Conduct, I see how this could cover any issue with LLMs, but now because of :

PostGIS welcomes and encourages participation by everyone. We are committed to being a community that everyone feels good about joining, and we will always work to treat everyone well. No matter how you identify yourself or how others perceive you: we welcome you.

 

but because of the Specific guidelines, especially those points :

*	Be empathetic, welcoming, friendly, and patient; "At the moment, LLMs are welcoming, friendly, and patient, but empathetic isn't part of what they can do."
*	Be inquisitive; "LLMs aren't inquisitive by default, they need to be properly prompted to do so."
*	Be concise; "This is the biggest pain with open source projects right now, they are really verbose and are using a lot of the efforts of reviewers." 
*	Step down considerately; "That is often an issue still, where either they don't acknowledge an issue, or they just repeat the same thing and pretend it's solved."

The biggest issue that needs to be resolved here is, who is the entity breaking the code of conduct when this happens? Is it the human that connected the LLM to the Repository, the agent instance, the agent software/version, the agent developers, the LLMs, the LLM flavour, the LLM Flavour and version, or the developers of the LLM. And how breaking the Code of Conduct is going to be applied?

 

I believe that if those are clearly addressed to clear the confusion, the code of conduct would be able to resolve any issue with humans, corporations or LLM.

 

Thanks,

Alex.

P.S. To clear any ambiguities about my opinions, I do not like LLMs nor the generative AI industry right now, I believe the it can be a really useful tool in the hands of someone qualified, but I still find the ethical issue of how they acquired their, data and how energy and hardware hungry these things are. But I'm also of the opinion that if someone decides to use them, they should do it properly and not be a net negative to society.

 

On Fri, 19 Jun 2026 at 07:02, Greg Troxel <gdt at lexort.com <mailto:gdt at lexort.com> > wrote:

I've stopped being maintainer of the pkgsrc package and am signing off
the list.  I wish you well in postgis development!




 

-- 

Alexandre Lessard

DevOps - Mapgears

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260619/fe1f472e/attachment-0001.htm>

From alexandre.lessard at mapgears.com  Fri Jun 19 11:01:37 2026
From: alexandre.lessard at mapgears.com (Alexandre Lessard)
Date: Fri, 19 Jun 2026 14:01:37 -0400
Subject: LLM policy
In-Reply-To: <000801dd0005$95e03c00$c1a0b400$@pcorp.us>
References: <rmiv7bsj9x5.fsf@s1.lexort.com> <rmibjd6eqth.fsf@s1.lexort.com>
 <CADymMJAABeUCbc1B7Dho_UmOmiFPLnYEituKZHiXkAvHOgdMVQ@mail.gmail.com>
 <000801dd0005$95e03c00$c1a0b400$@pcorp.us>
Message-ID: <CADymMJCcFU_rabr5FUY5Kk0z-ZT9XMVGuR82xzWPerxpb9OPeg@mail.gmail.com>

Thanks,

I've realized that I had missed a good chunk of the discussion because my
email service decided that it was spam !?

I personally like this conclusion, it's still protecting the openness of
Open Source and at the same time giving an exit door in case the time of
the maintainers isn't respected.

I'm sad that to see all the divisions that LLMs are causing in open source
projects, I keep myself informed on the subject and there's a few clashes
that happened in the last few months around open source projects. I'm
neither for nor against AI in the projects of others, but I'm against
reviewing extruded code from someone that doesn't understand what they are
doing and disrespects the valuable time of maintainers.

For the "Assisted by" requirement, there's one big plus for having it. In
the case there's changes in the court of law about the legality of AI code
using copyrighted content, it would make it easier to find the affected
commits in case the law forces people to revert those. And with the
precedent the US Supreme court has made a few months back; "works created
solely by AI are not eligible for registration under the current rules.";
Only work with "Sufficient human involvement" can be copyrighted at the
moment. So it would also make it clear which parts of postgis are protected
by the Group's copyrights, and which parts aren't.

Thanks again for the extra clarification,
Alex.





On Fri, 19 Jun 2026 at 12:06, Regina Obe <lr at pcorp.us> wrote:

> Alex,
>
>
>
> Thanks for pointing all those things out.  I agree with all of them.
>
>
>
> There are two things we are thinking of:
>
>
>
>    1. Yes clarify our code of conduct
>    2. To Greg?s point who sadly left presumably because of irreconcilable
>    differences, and to strk?s conclusion, I think it?s worthwhile to make an
>    LLM policy and I?ve been reading the ones Greg pointed out to see what we
>    like and don?t like
>    https://lists.osgeo.org/pipermail/postgis-devel/2026-June/030773.html
>
>
>
> We have decided that yes ultimately the human is responsible for the
> actions of the LLM, but we also want to not discourage people from using
> them and are more concerned with setting up best practices of using LLM as
> best we can by experimenting with them ourselves to make it less likely
> that a user will inadvertently break our code of conduct.
>
>
>
> We are still experimenting with what do we consider good practices of
> using an LLM and as you can see @Sandro Santilli <strk at kbt.io> set up a
> repo here for that - https://gitea.osgeo.org/postgis/postgis-ai
>
> The idea being something like, we may decide not to allow LLM generated
> from new users, unless they?ve played at least once in our postgres-ai
> playpen.  I think that will help curve drive-by LLM pull requests, which we
> haven?t gotten any of yet to my knowledge aside from the ones Darafei has
> been generating.
>
>
>
> Also  we have decided that any contribution largely written by an LLM
> should have an Assisted By: <org> Model .
>
> Case in point -
> https://gitea.osgeo.org/postgis/postgis_tiger_geocoder/pulls/25
>
>
>
> I don?t know if anyone agrees with me or not, but I don?t want links back
> to the site of the org, because then it would just feel like marketing that
> org to others.  We were torn with Assisted By because:
>
>    1. Feels like just marketing
>    2. It?s the honest thing to do though and will flag that yes we need
>    to pay more attention to this PR because of generation of poorer code by
>    LLM (which I expect to improve with time)
>    3. It could get noisy as Darafei mentioned if a core contributor is
>    using it a lot for some tasks.  Strk had suggested maybe contributors that
>    want to use an LLM a lot, have the commits done by an ai proxy e.g. if
>    strk?s ai was writing the code, it would be strk-ai (as the author), but of
>    course strk would be the one to merge it and be responsible for having
>    merged it.  Then in that case, strk-ai bio would show the details of models
>    used etc.
>    4. At what point do you say you don?t need to disclose.  E.g. If I use
>    a search AI mode on a search engine to write a line of code I am struggling
>    with, do I need to say Assisted By?  Cause I would never write that when I
>    do a seach engine search to find someone who has had the same problem and
>    use that person?s recipe.  I wouldn?t write ?Assisted-By: DuckDuckGo? in my
>    commit notes, though I may provide a link to where I got the answer in the
>    pull request description.
>
>
>
>
>
> Darafei has been experimenting with LLMs and he did say it is taking him a
> bit of time to review some of these.  So we might put another restriction
> like, No big patches period,
>
> unless you have made contributions in the past, cause we don?t have faith
> in you yet that you can review your code.  If a core contributor does it we
> of course expect the contributor to have thoroughly reviewed before
> applying and thus can commit any size.
>
>
>
> So that would be a simple reject and we can even auto do that ? any patch
> written by someone for the first time can?t be longer than X characters
> total.
>
> That would force users to solve simpler problems before they try to solve
> larger ones and prove that they are not just a drive-by patcher.
>
>
>
> *From:* Alexandre Lessard <alexandre.lessard at mapgears.com>
> *Sent:* Friday, June 19, 2026 10:22 AM
> *To:* postgis-devel at lists.osgeo.org
> *Subject:* Re: LLM policy
>
>
>
> After re-reading the Code of Conduct, I see how this could cover any issue
> with LLMs, but now because of :
>
> PostGIS welcomes and encourages participation by everyone. We are
> committed to being a community that everyone feels good about joining, and
> we will always work to treat everyone well. No matter how you identify
> yourself or how others perceive you: we welcome you.
>
>
>
> but because of the Specific guidelines, especially those points :
>
>    - Be empathetic, welcoming, friendly, and patient; "At the moment,
>    LLMs are welcoming, friendly, and patient, but empathetic isn't part of
>    what they can do."
>    - Be inquisitive; "LLMs aren't inquisitive by default, they need to be
>    properly prompted to do so."
>    - Be concise; "This is the biggest pain with open source projects
>    right now, they are really verbose and are using a lot of the efforts of
>    reviewers."
>    - Step down considerately; "That is often an issue still, where either
>    they don't acknowledge an issue, or they just repeat the same thing and
>    pretend it's solved."
>
> The biggest issue that needs to be resolved here is, who is the entity
> breaking the code of conduct when this happens? Is it the human that
> connected the LLM to the Repository, the agent instance, the agent
> software/version, the agent developers, the LLMs, the LLM flavour, the LLM
> Flavour and version, or the developers of the LLM. And how breaking the
> Code of Conduct is going to be applied?
>
>
>
> I believe that if those are clearly addressed to clear the confusion, the
> code of conduct would be able to resolve any issue with humans,
> corporations or LLM.
>
>
>
> Thanks,
>
> Alex.
>
> P.S. To clear any ambiguities about my opinions, I do not like LLMs nor
> the generative AI industry right now, I believe the it can be a really
> useful tool in the hands of someone qualified, but I still find the ethical
> issue of how they acquired their, data and how energy and hardware hungry
> these things are. But I'm also of the opinion that if someone decides to
> use them, they should do it properly and not be a net negative to society.
>
>
>
> On Fri, 19 Jun 2026 at 07:02, Greg Troxel <gdt at lexort.com> wrote:
>
> I've stopped being maintainer of the pkgsrc package and am signing off
> the list.  I wish you well in postgis development!
>
>
>
>
> --
>
> Alexandre Lessard
>
> DevOps - Mapgears
>
>
>


-- 
Alexandre Lessard
DevOps - Mapgears
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260619/715d2c1f/attachment.htm>

From pramsey at cleverelephant.ca  Fri Jun 19 13:14:16 2026
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Fri, 19 Jun 2026 13:14:16 -0700
Subject: lwnurbscurve_construct
Message-ID: <CACowWR1m6wCQgdNnwT+JTcWJ063v1usiMSgfx2Bq1E1PPzckTA@mail.gmail.com>

Loic,

In lwnurbscurve_construct the weights and knots are deep copied, but
the ptarray is passed in and ownership taking in the lwgeom, why so?
Why not just passively take ownership of all the input arrays?

https://github.com/postgis/postgis/blob/master/liblwgeom/lwgeom_nurbs.c#L139

Also wondering why the source file is not lwnurbscurve.c to match up
with the other type-specific files (lwline.c, lwpoint.c, lwpoly.c)
that contain constructors and the like.

P.

From even.rouault at spatialys.com  Sun Jun 21 05:02:41 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Sun, 21 Jun 2026 14:02:41 +0200
Subject: 177 pull requests in 4 days by a single "person" !?!
In-Reply-To: <462c2390-c698-45d3-8935-7a7d7c5cfa23@spatialys.com>
References: <462c2390-c698-45d3-8935-7a7d7c5cfa23@spatialys.com>
Message-ID: <0ae4bc71-fe17-4fc4-bd5b-d34fc89891bf@spatialys.com>

It is not just about opened PRs. Looking at 
https://github.com/postgis/postgis/commits/master/, I also see lots of 
commits without any sign of third party reviews.

Le 21/06/2026 ? 13:47, Even Rouault a ?crit?:
> Hi,
>
> PostGIS is one of the flagship FOSS4G projects and it is very 
> concerning to see it turning into a AI slop project. 
> https://github.com/postgis/postgis/pulls shows 177 PRs (and still 
> growing) opened by the same "entity" in the last 4 days. Don't say to 
> me there was a human in the loop !? It looks like a full autonomous 
> "agent" without any human control. Who is going to review that?
>
> Wake up folks. Human may not always be kind among themselves, but a 
> future where they have to mostly deal with bots is certainly to?be 
> even worse.
>
> Even
>
-- 
http://www.spatialys.com
My software is free, but my time generally not.
LLMs contribute to global warming


From even.rouault at spatialys.com  Sun Jun 21 04:47:29 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Sun, 21 Jun 2026 13:47:29 +0200
Subject: 177 pull requests in 4 days by a single "person" !?!
Message-ID: <462c2390-c698-45d3-8935-7a7d7c5cfa23@spatialys.com>

Hi,

PostGIS is one of the flagship FOSS4G projects and it is very concerning 
to see it turning into a AI slop project. 
https://github.com/postgis/postgis/pulls shows 177 PRs (and still 
growing) opened by the same "entity" in the last 4 days. Don't say to me 
there was a human in the loop !? It looks like a full autonomous "agent" 
without any human control. Who is going to review that?

Wake up folks. Human may not always be kind among themselves, but a 
future where they have to mostly deal with bots is certainly to?be even 
worse.

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.
LLMs contribute to global warming


From me at komzpa.net  Sun Jun 21 16:20:37 2026
From: me at komzpa.net (=?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?=)
Date: Mon, 22 Jun 2026 03:20:37 +0400
Subject: "Fix all tickets" experiment interim report
Message-ID: <CAC8Q8tLSexYon7QxdA+3fqjfX5g7qqhwf70xvnXWV1jWHN6BFw@mail.gmail.com>

Hi,

 - we had ~331 open tickets in PostGIS, which we have previously classified
as not critical or into the Fund Me category.
https://trac.osgeo.org/postgis/report/31. These user requests have been
hanging around in the backlog for 5-15 years typically.

 - for at least around 200 (~80%) of these it is possible to produce a
patch and test coverage using AI (codex-cli). I've pushed them as pull
requests on github to get a review from CodeRabbit. I have not merged any
"blindly".

 - non-fixable tickets are due to various reasons - related to bug reports
to upstream GDAL, GEOS, SFCGAL or Postgres machinery; major design changes
(coordinate epochs, exact curve area, geography clustering ...), or working
in combination with something else (pgAdmin, OSGeoLive, windows installer,
etc); many topology tickets covering architecture that needs to be designed
(batch loading, repair utilities, index churn, staged noding) or similar
raster design gaps (masks, aggregate semantics, multi-raster GDAL export).

 - some of the tickets proved to be invalid and discussion in the chat led
us to understanding how to improve documentation (need better explanations
on why planar operations on geodetic crs aren't always giving expected
results).

 - some improvements in tests (new oss-fuzz targets) uncovered more issues
to get fixed in existing codebase - thanks Even Rouault for addressing some
of these before.

 - discussion on adopting AI/LLM policy is also going on. Something along
the lines of Linux Kernel's
https://docs.kernel.org/process/coding-assistants.html - generally covered
by existing policies, but with separate entry point for the interested in
it specifically.

 - 43 of the smaller PRs/tickets I had the time this week to review,
iterate on and get merged.

 - got some first thanks from users.

Thanks Sandro Santilli, Lo?c Bartoletti, Lars Aksel Opsahl, Regina Obe,
Paul Ramsey, Dan Baston for bringing in your comments, reviews and notes
this week.

What's next:

 - A side product of this experiment is a set of notes on how the developer
documentation needs to be improved so that some of the "obvious" things and
procedures are recorded somewhere. I'll clean it up and bring it to a
separate review, I shared drafts in the matrix chat where myself and Sandro
are iterating on how to make docs target people and not machines.

 - Trac is showing its age. There is a slow ongoing discussion on how to
move to another forge, and how to not lose the tickets/id's/links in the
process. My hypothesis is that we can radically minimize the number of open
tickets before implementing any migration and thus have a much smoother
move. Reorganizing developer docs in repo to supersede trac wiki could also
help.

 - I plan to continue the review of the produced patches for closing the
currently open user's tickets.

Thanks,
Darafei.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260622/820ac471/attachment.htm>

From even.rouault at spatialys.com  Sun Jun 21 16:51:48 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Mon, 22 Jun 2026 01:51:48 +0200
Subject: "Fix all tickets" experiment interim report
In-Reply-To: <CAC8Q8tLSexYon7QxdA+3fqjfX5g7qqhwf70xvnXWV1jWHN6BFw@mail.gmail.com>
References: <CAC8Q8tLSexYon7QxdA+3fqjfX5g7qqhwf70xvnXWV1jWHN6BFw@mail.gmail.com>
Message-ID: <e6cbd88f-05a2-4b8c-95e8-13c241b8f4ee@spatialys.com>

>
> ?- some improvements in tests (new oss-fuzz targets) uncovered more 
> issues to get fixed in existing codebase - thanks Even Rouault for 
> addressing some of these before.

I don't appreciate at all to have served as a guinea pig of your 
experiments, and I'm not sure I'll fix any other PostGIS issue anytime 
soon, which you probably don't care if there isn't any more remaining. 
You don't conduct such experiment that creates hundreds of pull requests 
over a couple of days, and merging tens of them on the course of a week 
end without letting chance to others to review them, without having 
informed others in the community at large before (not speaking about 
potential private chat between insiders that might have occurred).

As a remainder: 
https://postgis.net/development/rfcs/rfc01/#when-is-a-vote-required : 
"Adding substantial amounts of new code", "Anything that might be 
controversial"

-- 
http://www.spatialys.com
My software is free, but my time generally not.
LLMs contribute to global warming and brain rot


From lr at pcorp.us  Sun Jun 21 22:09:01 2026
From: lr at pcorp.us (Regina Obe)
Date: Mon, 22 Jun 2026 01:09:01 -0400
Subject: "Fix all tickets" experiment interim report
In-Reply-To: <e6cbd88f-05a2-4b8c-95e8-13c241b8f4ee@spatialys.com>
References: <CAC8Q8tLSexYon7QxdA+3fqjfX5g7qqhwf70xvnXWV1jWHN6BFw@mail.gmail.com>
 <e6cbd88f-05a2-4b8c-95e8-13c241b8f4ee@spatialys.com>
Message-ID: <000201dd0205$3e7f3900$bb7dab00$@pcorp.us>

> >  - some improvements in tests (new oss-fuzz targets) uncovered more
> > issues to get fixed in existing codebase - thanks Even Rouault for
> > addressing some of these before.
> 
> I don't appreciate at all to have served as a guinea pig of your experiments,
> and I'm not sure I'll fix any other PostGIS issue anytime soon, which you
> probably don't care if there isn't any more remaining.
> You don't conduct such experiment that creates hundreds of pull requests over
> a couple of days, and merging tens of them on the course of a week end
> without letting chance to others to review them, without having informed
> others in the community at large before (not speaking about potential private
> chat between insiders that might have occurred).
> 
> As a remainder:
> https://postgis.net/development/rfcs/rfc01/#when-is-a-vote-required :
> "Adding substantial amounts of new code", "Anything that might be
> controversial"
> 
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
> LLMs contribute to global warming and brain rot


Darafei,

I think we should not make any more changes to 3.7.0 until we've released except for any regressions that show up as a result of 3.7.0alpha1.
I'm hoping to ship out 3.7.0alpha1 this week, so the less churn we have the better.

Don't take that as a message that I don't appreciate the work.  What I see here so far is great and I do believe you spent a great deal of time checking correctness.
Given that you managed to not crash the garden tester.  People always crash the garden tester when they make a pile of changes.

It's just a little too fast for comfort and making several people very concerned at the ability to really confidently test all of this. 
I'd like to see if users run into any issues in 3.7.0alpha1 with what we've changed so far.

As part of an LLM policy, we should require an additional committer check the code before it gets committed unless if it is less than x lines of code (to be agreed on).

Thanks,
Regina


From lnicola at dend.ro  Sun Jun 21 22:51:31 2026
From: lnicola at dend.ro (=?UTF-8?Q?Lauren=C8=9Biu_Nicola?=)
Date: Mon, 22 Jun 2026 08:51:31 +0300
Subject: "Fix all tickets" experiment interim report
In-Reply-To: <CAC8Q8tLSexYon7QxdA+3fqjfX5g7qqhwf70xvnXWV1jWHN6BFw@mail.gmail.com>
References: <CAC8Q8tLSexYon7QxdA+3fqjfX5g7qqhwf70xvnXWV1jWHN6BFw@mail.gmail.com>
Message-ID: <e074873f-9a9a-429d-ab61-87223c1a9430@app.fastmail.com>



On Mon, Jun 22, 2026, at 02:20, Darafei "Kom?pa" Praliaskouski wrote:
>  - for at least around 200 (~80%) of these it is possible to produce a patch and test coverage using AI (codex-cli). I've pushed them as pull requests on github to get a review from CodeRabbit. I have not merged any "blindly".
Hi, 

Just to be clear, you *did* review the changes yourself, right? Besides the AI review.

Laurentiu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260622/71f57524/attachment-0001.htm>

From alexandre.lessard at mapgears.com  Mon Jun 22 07:51:10 2026
From: alexandre.lessard at mapgears.com (Alexandre Lessard)
Date: Mon, 22 Jun 2026 10:51:10 -0400
Subject: "Fix all tickets" experiment interim report
In-Reply-To: <e074873f-9a9a-429d-ab61-87223c1a9430@app.fastmail.com>
References: <CAC8Q8tLSexYon7QxdA+3fqjfX5g7qqhwf70xvnXWV1jWHN6BFw@mail.gmail.com>
 <e074873f-9a9a-429d-ab61-87223c1a9430@app.fastmail.com>
Message-ID: <CADymMJBkrxGxWSxLRWa+DQ_d5haLvaUT_TvfdFr-tKdskO1tuQ@mail.gmail.com>

I thought that the repository postgis-ai was created for this kind of
tests, am I wrong?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260622/e5c83bc1/attachment.htm>

From lr at pcorp.us  Mon Jun 22 14:09:26 2026
From: lr at pcorp.us (Regina Obe)
Date: Mon, 22 Jun 2026 17:09:26 -0400
Subject: "Fix all tickets" experiment interim report
In-Reply-To: <CADymMJBkrxGxWSxLRWa+DQ_d5haLvaUT_TvfdFr-tKdskO1tuQ@mail.gmail.com>
References: <CAC8Q8tLSexYon7QxdA+3fqjfX5g7qqhwf70xvnXWV1jWHN6BFw@mail.gmail.com>
 <e074873f-9a9a-429d-ab61-87223c1a9430@app.fastmail.com>
 <CADymMJBkrxGxWSxLRWa+DQ_d5haLvaUT_TvfdFr-tKdskO1tuQ@mail.gmail.com>
Message-ID: <000001dd028b$68a079c0$39e16d40$@pcorp.us>

Postgis-ai is still a very much work in progress, hard to push stuff to it.  The postgis-ai is more for new users wanting to submit work than for our core team.

Darafei is a PSC member.  Perhaps he was a little too exhuberant for people?s liking, but I would hardly call his work AI slop.

 

Darafei as far as mistakes go has probably the very best track record of not making mistakes in our team and I suspect his use of AI is not going to change that.

 

Of the general scans I?ve done of his AI pull requests, I think they are well thought out and executed and I?m so happy he included tests, cause we tend to be too lazy to add tests even when we are fixing bugs. 

All these pull requests are bug fixes (no new features to my knowledge).  I am confident we won?t have any problems in 3.7.0alpha1 with these pull requests.

 

Thanks,

Regina

 

 

From: Alexandre Lessard <alexandre.lessard at mapgears.com> 
Sent: Monday, June 22, 2026 10:51 AM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Subject: Re: "Fix all tickets" experiment interim report

 

I thought that the repository postgis-ai was created for this kind of tests, am I wrong?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260622/530b0321/attachment.htm>

From me at komzpa.net  Mon Jun 22 14:24:57 2026
From: me at komzpa.net (=?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?=)
Date: Tue, 23 Jun 2026 01:24:57 +0400
Subject: "Fix all tickets" experiment interim report
In-Reply-To: <CADymMJBkrxGxWSxLRWa+DQ_d5haLvaUT_TvfdFr-tKdskO1tuQ@mail.gmail.com>
References: <CAC8Q8tLSexYon7QxdA+3fqjfX5g7qqhwf70xvnXWV1jWHN6BFw@mail.gmail.com>
 <e074873f-9a9a-429d-ab61-87223c1a9430@app.fastmail.com>
 <CADymMJBkrxGxWSxLRWa+DQ_d5haLvaUT_TvfdFr-tKdskO1tuQ@mail.gmail.com>
Message-ID: <CAC8Q8tJa9DTx0SDeG9jx3XPaYfZqTpgmEUMU6F48uLgLueKdow@mail.gmail.com>

On Mon, Jun 22, 2026 at 9:52?AM Lauren?iu Nicola <lnicola at dend.ro> wrote:

> Just to be clear, you *did* review the changes yourself, right? Besides
> the AI review.
>

Yes I did. I take full responsibility for supporting the changes I commit,
as usual in all the years.

On Mon, Jun 22, 2026 at 6:51?PM Alexandre Lessard <
alexandre.lessard at mapgears.com> wrote:

> I thought that the repository postgis-ai was created for this kind of
> tests, am I wrong?
>

That repository was created by Sandro as part of discussion on reorganizing
"machine readable" docs into it. I believe we can just make normal
human-targeting docs better and don't need a special place for "machine
readable" docs. The current shape of postgis-ai repository is more suitable
for a "support agent" that lives in the chat and answers questions rather
than the coding agent. If someone wishes to get something like openclaw
running on top of postgis-ai repo and matrix channel I can get behind the
initiative.

Thanks,
Darafei.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20260623/bda576f4/attachment.htm>

From lr at pcorp.us  Mon Jun 22 14:26:17 2026
From: lr at pcorp.us (Regina Obe)
Date: Mon, 22 Jun 2026 17:26:17 -0400
Subject: PostGIS Tiger Geocder 2025.1 released
Message-ID: <000501dd028d$c41d1ef0$4c575cd0$@pcorp.us>

PostGIS Tiger Geocoder 2025.1 extension released.
This is the very first release of PostGIS Tiger geocoder since it separated
from core postgis repository.
The upcoming PostGIS 3.7.0 will not include the postgis tiger geocoder.

Details of the release are here -
https://postgis.net/2026/06/PostGIS-Tiger-Geocoder-2025.1/

Raw Source:
https://download.osgeo.org/postgis/source/postgis_tiger_geocoder/postgis_tig
er_geocoder-2025.1.tar.gz
Md5:
https://postgis.net/stuff/postgis_tiger_geocoder/postgis_tiger_geocoder-2025
.1.tar.gz.md5

There are prebuilt extension files for windows users here -
https://winnie.postgis.net/download/windows/ (pg16 - pg18) windows users.
https://winnie.postgis.net/download/windows/pg18/buildbot/postgis_tiger_geoc
oder-pg18-2026.1w64.zip

Since this is all plpgsql/sql code, these extension files should work for
any system, though I haven't confirmed)

If you run into any issues - you may report them here -
https://gitea.osgeo.org/postgis/postgis_tiger_geocoder/issues

Thanks,
Regina and rest of PostGIS Development Team