[gdal-dev] Considering drivers removal ?

[Even Rouault]

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