comments about meeting agenda

[Greg Troxel]

"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.