comments about meeting agenda

[Greg Troxel]

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.