[gdal-dev] Considering drivers removal ?

[Even Rouault]

On mardi 12 janvier 2021 12:56:13 CET Frank Warmerdam wrote:
> On Tue, Jan 12, 2021 at 12:38 PM Howard Butler <howard at hobu.co> wrote:
> > The only question that matters here is "Who is going to maintain it?" and
> > if the answer to that is "no one", it should be removed. There doesn't
> > need
> > to be any meetings because the only criteria that matters is if someone is
> > willing to maintain it. We should provide the list of drivers and assign
> > the GitHub handles that step forward to be responsible for each. If
> > obscure
> > government one-offs formats have an audience of downtrodden government
> > users forced to use them, they need to put their handle in and take
> > ownership. They then need to find the time, money, or attention to carry
> > things forward.
> 
> Howard / Even,
> 
> I'd be willing to commit to maintaining some of the archaic drivers that
> meet the conditions I mentioned (buildable, testable in core build).  If
> Even would like I can provide a sublist of those he proposed i'd be willing
> to be responsible for.

NTv1: this is the perfect example of a driver of absolutely no use in 2021. 
Unless I'm wrong, there was only one single public dataset for that format, 
ntv1_can.dat, and it is now available as GeoTIFF in
https://github.com/OSGeo/PROJ-data/blob/master/ca_nrc/ca_nrc_ntv1_can.tif

My current plan is:

- for BPG, E00GRID, EPSILON, IGNFHeightASCIIGrid, ISG, Aeronav FAA, BNA, HTF, 
OpenAir, SEG-P1, SEG-Y, SUA, X-Plane, move *now* driver code, documentation  
and tests to https://github.com/OSGeo/gdal-extra-drivers which is a slightly 
improved version of a cemetery repository, since it includes a build script to 
create a plugin. I have no plan to maintain that repository after that initial 
move (that means I won't merge pull requests unless someone else steps up for 
the role) and it will likely break in the future. I'd wish we would agree to 
move more drivers there. And probably most future drivers for esoteric formats 
should go there.
Those drivers are ones I've authored, that received no significant 
contribution from anyone else AFAIR, no-one paid development for and I suspect 
are close to be unused. So hopefully no one should have bad feelings with them 
going away. It was a bad taste of mine to have put them in GDAL to start with.
Why did I picked up the extra repository after all ? A tiny fraction of them 
might be useful like ISG or IGNFHeightASCIIGrid in some contexts (to create 
grids for PROJ), but definitely not for general purpose. So as far as I'm 
concerned, I'll go through the extra step of building the extra repository or 
a subset of it if I've an occasional need for them.

- proceed as I mentionned initially for other drivers I listed and no-one 
steps up to maintain, with the variation of moving the code to gdal-extra-
drivers instead of just removing them (but potentially not including a build 
recipee for them in the build script, if that proves to be too complex).

The issue with esoteric/legacy drivers is not that much maintenance of the 
actual code of the drivers, in the sense of dealing with bug reports, 
questions, etc. (pretty sure they are none for the ones I listed). Most of 
them must work reasonably well and be feature complete, and most 
vulnerabilities have now been fixed. My concern is that this legacy code has 
indirect costs on other GDAL developers and users. The psychological cost I 
mentionned. Let's say someone want to turn on higher warning levels, and that 
this breaks in tens of drivers. Would he have to ping every maintainer and 
wait for them to address the issue ? Or maybe he will just give up. Similarly 
for breaking changes in the driver API. As Sean mentionned, this is probably a 
serious obstacle to growing up the core development team.


Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com