Attending

Andrea Aime

Kevin Smith

Torben Barsballe

Gabriel Roldan

Ian Turton

Actions from last meeting:

   -

   [DONE] Nils: Discuss  GS Docker image on email list, proposal
   <https://github.com/geoserver/geoserver/wiki/Proposals> to follow (see dev
   guide <https://docs.geoserver.org/latest/en/developer/policies/gsip.html>
   )
   -

   Justin: PR to remove himself as maintainer various pom.xml files
   -

   Kevin: Review pom.xml for “boundless” :)
   -

   [DONE] All: Join the Bolsena code sprint for July 2nd and 3rd
   -

   Jody: [DONE] Ask attendees their address, and send food / beer /
   breakfast as appropriate (ended up with t-shirts)

Agenda

   -

   2.17.3 release date
   -

   Rename master branch?
   -

   Jenkins concurrent builds
   -

   GeoServer microservices project
   -

   GeoTools GeoJSON store upgrade (
   https://github.com/geotools/geotools/pull/3051)
   -

   Sprint Updates

Actions

   -


2.17.3 release date

Yep, really 2.17.3.

https://github.com/geoserver/geoserver/wiki/Release-Schedule

Will be done in parallel with 2.18, will figure out the logistics and
precise day when we get there.
Rename master branch?

No.

We are all masters here, there are no slaves!

Would require considerable changes to build server config. If someone wants
to do the work, we can reconsider then.

https://osgeo-org.atlassian.net/browse/GEOS-9647

Also reference to GitHub: https://www.bbc.co.uk/news/technology-53050955

If we were to change, the following would have to be modified too:

   -

   The developer guide
   -

   Jenkins builds and potentially release scripts
   -

   PR checks (some of them, the cross-project one for example)
   -

   Documentation redirects/aliases (e.g.
   https://docs.geoserver.org/master/en/user/ etc.)

Jenkins concurrent builds

See email for background.

   -

   Builds cannot share the same workspace
   -

   All the main branches have their own workspaces
   -

   The java 11 builds do not have this … should we do something similar.


Maven local repository is not designed to be accessed by multiple builds:

   -

   We can consider making a separate maven repo for each build category?
   -

   https://github.com/takari/takari-local-repository
   -

      we looked at this also during “new branch release” multithreaded
      build issues
      -

   Just a geoserver build weighs in about 5G


Q: what is A,B,C?

   -

   We cycle through master, stable, maintenance, so they are arbitrary
   labels

Q: can we have “master”, “even”, “odd”?

   -

   Yes, but you have to change all the jobs by hand (jenkins is not smart
   about this rename)
   -

   Check release guide for update instructions…


See:
https://docs.geoserver.org/latest/en/developer/release-guide/index.html#if-you-are-cutting-the-first-rc-of-a-series-create-the-stable-branch
GeoServer microservices project

Customer requirements:

   -

   HA
   -

   No filesystem
   -

   Dockerized environment


Compare:

   -

   Catalog with https://github.com/planetlabs/stratus (thick geoserver) on
   spring boot without filesystem, with a redis catalog, has a deep fork of
   GWC, good service startup fast
   -

      GWC extensibility
      -

      CachingCatalogFacade
      
<https://github.com/planetlabs/stratus/blob/master/src/stratus-redis-catalog/src/main/java/stratus/redis/cache/CachingCatalogFacade.java>
      -

      An example of difficult workarounds get spring boot and GeoServer to
      work
      -

         XML vs Annotation-based config:
         https://jira.spring.io/browse/SPR-7028
         -

   JDBC Config, still poor layer lookup performance with many layers (tens
   of thousands) (tested spring 2020)



Besides running separate microservices in a filesystem-less infrastructure,
a by-product goal is to come up with per-service dimensioning specs for
different workloads.

It also involves running on Java 14 and investigating the benefits and/or
tradeoffs of using the ZGC. On the bright side, for containerized apps, it
returns unused heap to the operating system, on the dark side, looks like
it may report higher memory usage than it's actually using.

Choice:

   -

   Do as a cluster of community modules
   -

   Eventually it could be a separate project under geoserver's github
   organization
   -

   A mixin of the above two


GeoTools GeoJSON store upgrade

Trying to get rid of gt-geojson, based on simple-json, and move to jackson.
Part of the “bug fix” sprint too. Long term, replace json-lib generator too.
Bug fix Sprint

Thanks for participating
<https://docs.google.com/spreadsheets/d/1Gh2dK0JKp-4TuU73gvisKvtt2OQ5IoCX8BrM4AaZMts/edit?usp=sharing>
.

A bump in fixes!

GeoServer


JTS 1.17.0 update, API change on geometry.reverse() causing some API
changes for us <https://github.com/geotools/geotools/pull/3034>.
Unchecked warnings cleanup

Begin of it: https://github.com/geotools/geotools/pull/3043

   -

   Approach: fix the easy ones, ignore the complicated ones like RangeSet
   -

   Community interest
   -

      make a public geotools branch for this cleanup
      -

      Andrea to setup a google doc
      -

   Example: gt-main has 700 warnings
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to