[gdal-dev] Considering drivers removal ?

[Stephen Woodbridge]

On 1/12/2021 5:36 PM, Even Rouault wrote:
> 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
>
Even,

Just want to say this sounds like good plan to me, not that my input 
means a lot. I also want to say Thank You! for all your hard work 
supporting this and other projects, but answering my questions through 
the years. I've had a lot of roles in my career in open source and 
industry and can appreciate the difficult balance between compatibility 
with legacy code and the need to break free of it to move forward. It's 
hard and I never enjoyed having to make those decisions, but you have my 
respect and support whatever you decide.

Thank You! again for your efforts and support!

-Steve W