[gdal-dev] Considering drivers removal ?

[Howard Butler]

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 <mailto: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 <mailto: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 <mailto: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 <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 <mailto:thomas.bonfort at gmail.com>> wrote:
> 
> 
> On Tue, Jan 12, 2021 at 11:36 PM Even Rouault <even.rouault at spatialys.com <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20210128/0e822b33/attachment.html>