Hi, trying to answer the different points raised up to now:
- SVG: let's keep it as it is used. This is exactly the feedback I'm seeking for. I had developed this as a toy, crazy me, I won't do it anymore. No idea anyone was using it actually. - making those driver plugins. This would require significant work, and the purpose is to save work. Our current build infrastructure is not ready for easy plugification. And announcing they will be unmaintained is probably not efficient to know in advance the impact of the planned breakage. People don't read documentation. The only way to force people to react is to break them in some way. - regarding Python, I'm not sure what the question is exactly. If it was how to still enable the drivers candidate for retirement to work, then it is just gdal.SetConfigOption('GDAL_ENABLE_DRIVER_FOO', 'YES') - once we have decided which drivers should be retired, I don't find moving them to some cemetery repository very useful. Because that would lack part of the build scripts. What would be more useful is to add a paragraph in the documentation that drivers FOO, BAR, BAZ were retired in GDAL 3.5. That way people know they have to download a GDAL tarball or checkout a git tag before that release, or download a past OSGeo-Live VM, or Conda package, etc... And they will get (hopefully) functional code. Much better than the cemetery approach. - regarding schedule: * GDAL 3.3, May 2021: version with drivers semi-retired * GDAL 3.4, November 2021: still with drivers semi-retired * GDAL 3.5, May 2022: retired drivers are gone So we won't get much feedback from Ubuntu LTS april 2022, as at that date, the drivers will have to be retired for the 3.5 release. - Where are the costs in keeping these drivers ? * monetary: there is one, but I'm unable to quantify it * environmental: burn CPU cycles each time someone does a GDAL build * psychological: prevent developers from doing modernization in GDAL internals. When you know you have to change 250 drivers, you think twice before doing the change, and generally you conclude it is not worth it, or fallback to hacks to limit the amount of code change. We should probably trim down the list to 20 raster and vector drivers to have a real effect regarding that. For a next time :-) Even -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev