[gdal-dev] Considering drivers removal ?

[thomas bonfort]

On Tue, Jan 12, 2021 at 11:36 PM Even Rouault <even.rouault at spatialys.com>
wrote:

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

Given that we have a relatively easy way to disable individual drivers at
compile time, could we expand on this mechanism to mark problematic drivers
as "orphaned" in this case? The code would still live in the repo but would
be effectively disabled until someone with sufficient interest invests the
time/money to update the problematic code and re-enable it.
This will of course create some overhead to keep track of which drivers
have been orphaned from one release to the next, create github
issues/labels to list which drivers need work to be re-enabled, etc... But
it shifts the burden of maintaining the codebase of 250 drivers from the
core team over to the people/companies who actually need them. I'd be
willing to contribute the scripts that could ease the process of
orphaning/reintegrating a specific driver.

Regards,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210127/e87bafbb/attachment.html>