[gdal-dev] Considering drivers removal ?

[David Brochart]

I am currently trying to add a Zarr driver to GDAL (see
https://github.com/OSGeo/gdal/pull/3411), but from what I can see the trend
is to remove drivers, so I'm now wondering it I should pursue this effort.
I'm relatively new to GDAL, but from my point of view supporting a lot of
formats is part of GDAL's success, so maybe the real focus should be on
implementing a plugin mechanism that would allow driver development
independently from core GDAL. Again, I might not have enough background to
give valuable feedback.

Regards,

David.

On Wed, Jan 27, 2021 at 12:34 PM thomas bonfort <thomas.bonfort at gmail.com>
wrote:

>
>
> 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
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210127/5d00d792/attachment.html>