[gdal-dev] Considering drivers removal ?

Thu Jan 28 14:34:59 PST 2021

+1 for RFCs for new drivers.

I took a couple minute run at what a template for the RFC might look like.
It's painfully rough.  Anyone wanting to edit the doc, let me know off list
and I'll give you edit priv.  Or make you own.  You are welcome to take any
or none of my draft text if you make your attempt at a template for a New
Driver RFC.  Should there even be a template?

https://docs.google.com/document/d/e/2PACX-1vTtIU3WJw0APd7fXqfGVAYrBQGgURIzizb9MiXCI1trkj4PxOBZmz9o-Ne_5P7zkymM7dPjVZOCHBXl/pub

On Thu, Jan 28, 2021 at 1:37 PM Howard Butler <howard at hobu.co> wrote:

> I am also supportive of RFC approvals before someone goes and invests the
> time to develop a driver. Otherwise it is easy to get in the spot where
> it's not merged because the community didn't want it included. A nice thing
> the RFC process would ensure is a full document of the expectations of the
> driver. Specifically, whether it depends on binary-only SDKs, what features
> it would support, and *who* is on the hook for responding to issues on it.
> Another feature of this RFC should be to clarify the deprecation and
> removal process for drivers that are no longer relevant or no longer have
> someone providing them attention.
>
>
> On Jan 28, 2021, at 1:33 PM, Tamas Szekeres <szekerest at gmail.com> wrote:
>
> 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
>>
> _______________________________________________
> 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/20210128/48241089/attachment-0001.html>