[gdal-dev] Considering drivers removal ?

[Mateusz Loskot]

+1 for RFC

Mateusz Loskot, mateusz at loskot.net
(Sent from mobile, may suffer from top-posting)

On Thu, 28 Jan 2021, 23:35 Kurt Schwehr, <schwehr at gmail.com> wrote:

> +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
>>
> _______________________________________________
> 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/4991a482/attachment.html>