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.bonf...@gmail.com> wrote: > > > On Tue, Jan 12, 2021 at 11:36 PM Even Rouault <even.roua...@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 > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
