[gdal-dev] Considering drivers removal ?

[Sean Gillies]

Hi Even,

On Mon, Jan 11, 2021 at 7:44 AM Even Rouault <even.rouault at spatialys.com>
wrote:

> 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')
>

Making users explicitly turn these formats back on feels good to me. I
don't see a downside to it. We might want to consider one round of warnings
before setting this option's default to NO? Doing so would take care of the
operators of deployed applications who *do* pay attention to warnings.

Would it make any sense to retire read and write of formats on a different
schedule? The fewer SDTS files written in the next 6-12 months, the less
impact there will be when we remove the driver.

When the change is made to GDAL, I might bikeshed about the config option
name a bit.


> - 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
>

Would we disable default compilation of these drivers in 3.3 as well? I'd
be in favor of that.

Thanks for writing that third bullet point. I've thought twice about
changes for exactly that reason.

Formats come and go. We can't expect the GDAL project and its maintainers
(mostly you!) to be the curators forever of all data.

-- 
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210111/baaefb1d/attachment.html>