GeoTools / GeoServer PMC meeting - 2024-04-23Attending -
Torben Barsballe - Andrea Aime - Jody Garnett - Jukka Rahkonnen - Peter Smythe Actions from prior meetings: - [DONE] Andrea: send an email for the release manager - [DONE] (no response yet) Jody: Reach out to Jo Cook (Astun) regarding core contributor status - [DONE] Jody: Propose adjustments to contributor policy requiring interaction on an individual (not organization) level Agenda - Crazy issue with Azure blobstore, and how to prevent it - GRIB backwards compatibility broken (with silver lining) - Mkdocs conversion getting it moving again - GSIP 224 discussion - Roadmap communication and chit-chat Actions - Jody: Make a PR for GSIP 224 <https://github.com/geoserver/geoserver/wiki/GSIP-224> - Peter: Make a similar proposal for GeoTools - Jody: Make a PR for geoserver-users transition to discourse Crazy issue with Azure blobstore, and how to prevent it GWC Report makes a massive amount of requests <https://github.com/GeoWebCache/geowebcache/issues/1149> to Azure blob store: - Deleting a layer / gridset resulted in an infinite loop due to a … jackson upgrade resulting in a regression - API uses JSON, we use jackson to parse the JSON including the token to page through results … and token was null when reaching the end - Jackson upgrade changed null to empty string, so infinite loop Can we run tests? - There is a cost (paid account), but for an infinite loop this would be expensive … - emulator + client library are a matched set - so we need to migrate to newer client library to make use of the API - Azure / S3 / etc… all have this lack of infrastructure to test against problem There is a public ticket here, but has not attracted interest / fix… - 33000 requests per min is expensive! - Fix was to check for empty string This is a good example of where the PSC can ask for funding? - Would have to set a hard limit of build server use (for each day a specific number of calls etc…) - This is also an example of shared risk, someone found the 33000 requests per min and reported it (so it was available for others to see and work on). - So we could estimate the cost to setup a “cloud infrastructure” testing … GRIB backwards compatibility broken (with silver lining) - Follow on to this from a few meetings ago … - Manual upgrade process documented <https://docs.geoserver.org/latest/en/user/installation/upgrade.html#grib-layers-geoserver-2-26-and-newer> (also for GeoTools <https://docs.geotools.org/latest/userguide/welcome/upgrade.html>)… - Can kind of guess and rewrite the variable names - But the time format changes so still some risk.. - We do expect time format to change once again (hopefully before September release cycle) - With all this … success we are now on a supported version netCDF library - Quite a bit faster (example 20x), especially on a network … mkdocs conversion getting it moving again - Jody is back from travel and available to work on this again - available on pypi: https://pypi.org/project/mkdocs-translate/0.4.0/ - tested by Andrea, can make it run, however breaking on pandoc - jody is using pandoc 3.1.7 (installed via homebrew) - latest is 2 weeks ago: pandoc 3.1.13 (pip only has up to 2.3, Mint up to 2.9) - GeoCat will provide a tester to help with the remaining A/B testing Examples of the kind of RST fixes to expect: - closed: https://github.com/geoserver/geoserver/pull/7429 applied fixes (yet to be backported) - open: https://github.com/geoserver/geoserver/pull/7462 pending rst fixes GSIP 224 discussion GSIP 224 clarification about be grateful to companies (while explaining that commit access is extended to individuals): GeoServer is grateful that organizations of all shapes and sizes support our project with in-kind participation of their employees. Extending commit access is made to individuals directly based on their expertise demonstrated over time. Proposal is approved - Jody will take an action to make a PR for GSIP224 - Peter to make a similar proposal for GeoTools Roadmap communication and chit-chat 2024 Q1: https://geoserver.org/behind%20the%20scenes/2024/01/03/roadmap.html https://github.com/geoserver/geoserver/wiki/Maintenance-%26-Roadmap 2024 Q2: jody is considering making another news announcement. - goal would be to emphasis the in-kind contributions / commitment - any progress… - fundraising progress … not very much sadly Q: What roadmap items can be worked on now? - As spring-framework upgrade is “stuck” pending funding / in-kind? spring-security / spring-oauth-client upgrade: - this work can happen *now* no need to wait… - GeoCat asks if there are interested parties to work on this activity? - Considering in-kind participation if others are willing… - aside: email with Andreas Watermeyer offering to work on the upgrade. No status update since January wicket: - Upgrade to Wicket 9 can happen now no need to wait… - Brad has made a lot of progress towards Wicket 9 - GeoCat will offer in-kind A/B testing which we understand is needed - Open: Brad asked for assistance with the WicketDialog rewrite - Or can just suppress its deprecation for Wicket 9, and do the work for Wicket 10… - Q: Is anyone available to organize / plan with respect to the release cycle? - Andrea prefers to merge close to September (to avoid extra backport overhead…) - Andrea has been keeping this up to date with main ImageN: - Java 17 is upset running JAI due to javax package - This is also something that can be worked on now, no need to wait .. - In-kind thus far: - GeoCat is interested in this one also, provided it is a good time - Andrea made some roadmap planning ideas on JAI-EXT Q: Mass reformat with Palantir? - Still a good idea, wait until after Wicket upgrade :D Q: What about discourse? https://discourse.staging.osgeo.org/c/geoserver-users/12 - testing… - nice it works with OSGeo User ID - OSGeo user ID login did not work for Peter - nice it works with GitHub - feedback - modern / looks / better - alternative: - github discussions is okay, with any discussions occurring closer to development. May be a good replacement for geoserver-devel … Discussion: how to replace the email list? - email subscribers switch from sourceforge to discourse - get a feed of emails similar to mailman, and an address to reply to … - not sure we can test this on staging? It was disabled … What can we expected: - Does not really help with engagement, but helps lower a barrier to partipation - OSM took about a month to make the transition: https://lists.openstreetmap.org/pipermail/talk/2024-March/date.html SAC joins the chat - They could set up a mirror from sourceforge … - Setup an email address and subscribe it to sourceforge… - Send email to discourse and it would not send to sourceforge… - Q: How do they sign up discourse geoserver-users? - 1. Setup a “geoserver-users” group - 2. Allow users to join freely … - 3. The group is https://discourse.staging.osgeo.org/g/geoserver-users - 4. Associate a user geoserver-us...@osgeo.org with the group, so that email sent to this address is added to the discourse group Actions: Make a proposal? - Define a date to shut off geoserver-us...@sourceforge.net email list? - Setup production geoserver-us...@discourse.osgeo.org - Keep both running for a month, use this as an oppertunity to remind people to transition … - Collect a mailman dump for the month of overlap, and re-update discouse - Shut off source forge How to transition as an individual: 1. Login to discourse using (github / osgeo userid / oauth) 2. Register to the geoserver-us...@discourse.osgeo.org group 1. You automatically watch the group you join and get email notifications 2. You can reply to email from geoserver-us...@discourse.osgeo.org 3. Just like a mailing list … 3. Unsubscribe from https://sourceforge.net/projects/geoserver/lists/geoserver-users/unsubscribe
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
