[gdal-dev] Considering drivers removal ?

[Sean Gillies]

Hi Tamas,

Are you suggesting that a RFC be required for a new driver? I would support
this 100%.

On Wed, Jan 27, 2021 at 2:17 PM Tamas Szekeres <szekerest at gmail.com> wrote:

> 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
>>>
>>
-- 
Sean Gillies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210128/5d4af4bd/attachment.html>