<div dir="ltr"><div>Hi Even,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 11, 2021 at 7:44 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
trying to answer the different points raised up to now:<br>
<br>
- SVG: let's keep it as it is used. This is exactly the feedback I'm seeking <br>
for. I had developed this as a toy, crazy me, I won't do it anymore. No idea <br>
anyone was using it actually. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- making those driver plugins. This would require significant work, and the <br>
purpose is to save work. Our current build infrastructure is not ready for <br>
easy plugification. And announcing they will be unmaintained is probably not <br>
efficient to know in advance the impact of the planned breakage. People don't <br>
read documentation. The only way to force people to react is to break them in <br>
some way.<br>
<br>
- regarding Python, I'm not sure what the question is exactly. If it was how <br>
to still enable the drivers candidate for retirement to work, then it is just <br>
gdal.SetConfigOption('GDAL_ENABLE_DRIVER_FOO', 'YES')<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>When the change is made to GDAL, I might bikeshed about the config option name a bit.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- once we have decided which drivers should be retired, I don't find moving <br>
them to some cemetery repository very useful. Because that would lack part of <br>
the build scripts. What would be more useful is to add a paragraph in the <br>
documentation that drivers FOO, BAR, BAZ were retired in GDAL 3.5. That way <br>
people know they have to download a GDAL tarball or checkout a git tag before <br>
that release, or download a past OSGeo-Live VM, or Conda package, etc... And <br>
they will get (hopefully) functional code. Much better than the cemetery <br>
approach.<br>
<br>
- regarding schedule:<br>
   * GDAL 3.3, May 2021: version with drivers semi-retired<br>
   * GDAL 3.4, November 2021: still with drivers semi-retired<br>
   * GDAL 3.5, May 2022: retired drivers are gone<br>
 So we won't get much feedback from Ubuntu LTS april 2022, as at that date, <br>
the drivers will have to be retired for the 3.5 release.<br>
<br>
- Where are the costs in keeping these drivers ?<br>
   * monetary: there is one, but I'm unable to quantify it<br>
   * environmental: burn CPU cycles each time someone does a GDAL build<br>
   * psychological: prevent developers from doing modernization in GDAL <br>
internals. When you know you have to change 250 drivers, you think twice <br>
before doing the change, and generally you conclude it is not worth it, or <br>
fallback to hacks to limit the amount of code change. We should probably trim <br>
down the list to 20 raster and vector drivers to have a real effect regarding <br>
that. For a next time :-)<br>
<br>
Even<br></blockquote><div><br></div><div>Would we disable default compilation of these drivers in 3.3 as well? I'd be in favor of that.</div><div><br></div><div>Thanks for writing that third bullet point. I've thought twice about changes for exactly that reason.</div><div><br></div><div>Formats come and go. We can't expect the GDAL project and its maintainers (mostly you!) to be the curators forever of all data.</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Sean Gillies</div></div></div>