Thanks Martin: We do require PRs be made gainst main, and then backported.
No objection to you taking on s3-geotiff on our end, I caution that I do not think that module has an active developer to review your PR. Indeed we may need to set you up with commit access if you wish to work on a community module, you can see the developers guide <https://docs.geoserver.org/latest/en/developer/policies/community-modules.html> for details. Think about it, and reply to this email with your github id if you are interested in such a role (even for a couple of months while your team transitions to COG). -- Jody Garnett On Sun, 30 May 2021 at 13:23, Kalén, Martin <martin.ka...@sweco.se> wrote: > Hi, > > > > We have been using GeoServer 2.16.x with s3-geotiff support (in turn > supported by GeoTools) in a Docker-image for a customer’s WMS service, > recently upgraded to GeoServer 2.19.x where we hit [GEOS-9866]. > > > > I have seen that there is a new COG-module in GeoServer, but we need some > time to migrate so I have prepared a patch/potential Pull Request against > GeoTools for extending the life of s3-geotiff in GeoServer. This was done > by upgrading the GeoTools s3-geotiff EHCache-dependency to EHCache v3.0.4 > and adjusting the internal caching API accordingly. All unit tests pass and > the patched s3-geotiff was tested successfully with GeoServer v2.19.1. > > > I have just signed an individual CLA and gotten confirmation that it’s on > file at OSGeo. > > > > Any objections against creating a PR against GeoTools v25.x branch? Thanks. > > > > Best regards, > > Martin > > > > -- > > Martin Kalén > > Senior Consultant > > Sweco Sweden > > www.sweco.se > _______________________________________________ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel >
_______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
