[gdal-dev] Considering drivers removal ?

[Tamas Szekeres]

Hi Sean,

I would also be supportive to formalize the driver submission process.

Best regards,

Tamas


Sean Gillies <sean at mapbox.com> ezt írta (időpont: 2021. jan. 28., Cs,
17:39):

> 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/771e8c98/attachment-0001.html>