[gdal-dev] Considering drivers removal ?

[Tamas Szekeres]

David,

Up to this time the driver writers were highly welcomed to author new
drivers for the project and these effort didn't require a separate RFC in
terms of the Project Management Committee Guidelines
<https://gdal.org/development/rfc/rfc1_pmc.html> document. Adding new
drivers hasn't been considered to be substantial changes or something that
causes to change the API or brings in backwards incompatibility issues.
However in a real deployment situation the drivers may cause issues for the
developers, end users and package maintainers from several aspects like so:

1. The drivers may depend on external libraries and we don't want to link
against those libraries in all cases.
2. The external libraries may cause license incompatibilities, ie linking
against that may change the license terms of the overall project.
3. Not all of the drivers are required in a particular solution (that
applies to the built in drivers, too). In a real situation the application
may use only a limited set of drivers and the existence of the unwanted
drivers may cause some performance degradation.
4. Implementing custom compilations (and omitting unwanted drivers from the
build) may be problematic for most of the users or projects utilizing gdal
as a sub-project.

In my opinion, the current solution of incubating new drivers is fairly
minimalistic, we might probably want to know what kind of format is being
addressed, who is the audience, how amount of user might be of interest,
how the licensing of the dependent project is looking like, is the
dependent project (if any) maintained well enough and can be compiled to
each supported platforms etc.

But replying to the question, I think you shoud continue the effort, but
consider to implement a plugin build for that. There are several existing
drivers are compiled as plugins at the moment, so it should not be so
difficult.


Best regards,

Tamas


David Brochart <david.brochart at gmail.com> ezt írta (időpont: 2021. jan.
27., Sze, 15:29):

> 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
>>
> _______________________________________________
> 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/b037b194/attachment.html>