Attending
Andrea Aime
Jody Garnett
Jukka Rahkonen
Torben Barsballe
Kevin Smith
Actions from last meeting:- [DONE] Torben: Vote on Datastore Parameter proposal
- All: Volunteer for releases - [DONE] 2.18.1 in November, 2.17.4 in December
Agenda1. Travis CI replacement
-
December release volunteer
-
Unchecked branches status update
-
Java 11 modules units issue
-
Releasing or fixing an old branch
Actions- Jody: Create Ticket/Wiki for tracking Travis CI replacement
https://github.com/geotools/geotools/wiki/Migrate-Travis-builds
- Andrea: ask for a December release volunteer on list
Travis CI replacement
Cost of using Travis CI vs cost of migrating builds.
What do we need to migrate:
-
GeoServer → java 8, java 11, and QA builds
-
GeoTools → java 8, java 11, and QA builds
-
Linux environment available in github actions so this can be migrated
-
These should be “simple” to migrate, nothing complicated
-
GeoTools database builds
-
sqlserver, oracle, mysql 5, mysql 8
-
GeoServer documentation build
-
requires sphinx, so “not simple”
-
GeoTools documentation build
-
Note: unlikely to be effective, as sphinx not installed
-
GeoServer package build
-
Should be “simple” to migrate
Options:
-
Pay Travis
-
We have budget, we could look at value for paying
-
github Actions
-
Databases make of well-known service “postgis service”,is there an equivalent for Oracle, sqlserver and mysql 5/8?
-
Also worried about using only one tool, and everyone is switching to them.
-
Jenkins
-
The approach of adding a jenkins pipeline build to repository is important to allow anyone to work on this
-
Circle CI, we have had mixed success with the Windows build, and there is a time limit (think 50 minutes). GeoNode is using CircleCI. Apparently we’d get 4 concurrent builds for Linux.
-
Azure Pipelines is also an option.
GDAL migrated to GitHub Actions with https://github.com/OSGeo/gdal/pull/3194 and https://github.com/OSGeo/gdal/pull/3198
December release volunteer
https://github.com/geoserver/geoserver/wiki/Release-Schedule
Need a volunteer. Let’s ask on the list.
Unchecked branches status update
GeoTools: merged! Instructions here: https://docs.geotools.org/latest/developer/conventions/code/qa.html#javac
GeoWebCache: merged!
GeoServer: ongoing. https://github.com/geoserver/geoserver/pull/4567 Andrea currently working on WFS. EMF models source of warnings as collections have no generics in place, for the time being, they are being suppressed (IntelliJ seems to have a cleanup removing unnecessary annotations, if we fix the EMF models later).
GeoTools Java 11 modules units issue
Coming down to NetCDF use of units preventing startup:
-
Previously a hack using reflection was used to configure a DefaultFormatter
-
We need a new approach
Ongoing PR (breaks existing tests, removes code that can parse NetCDF units)
https://github.com/geotools/geotools/pull/3232 (nope!)
Some notes on how to possibly handle it in the javadoc of the class:
And in this ticket:
https://osgeo-org.atlassian.net/browse/GEOT-6709
https://github.com/unitsofmeasurement/uom-se/issues/201
We updated to Indriya 2.0.2 earlier in the year:
Discussion:
-
Can this fix be confined just to netCDF? I know units are used in more locations …. Nope.
-
GeoToolsUnitsFormatter may need to wrap, rather than configure, … but may not have required visibility access
-
Need someone familiar with units to do the job, might need funding
Releasing or fixing an old branch
Given funding it’s not a problem, it’s just not easy given how many things changed.
Jody would like to release:
-
GT 19.x / GWC 1.13.x / GS 2.13.x
-
I do not want to bother folks with pull-request against these
-
Some build changes to osgeo repo needed
Q: Do we backport between all the releases? 22.x, 21.x, 20.x … 19.x?
Not needed, PRs to 19.x can be clear … anyone needing 20.x can cherry-pick if needed to get that branch to build again also.