<div dir="ltr">I am currently trying to add a Zarr driver to GDAL (see <a href="https://github.com/OSGeo/gdal/pull/3411">https://github.com/OSGeo/gdal/pull/3411</a>), 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.<div><br></div><div>Regards,</div><div><br></div><div>David.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 27, 2021 at 12:34 PM thomas bonfort <<a href="mailto:thomas.bonfort@gmail.com">thomas.bonfort@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 12, 2021 at 11:36 PM Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
The issue with esoteric/legacy drivers is not that much maintenance of the <br>
actual code of the drivers, in the sense of dealing with bug reports, <br>
questions, etc. (pretty sure they are none for the ones I listed). Most of <br>
them must work reasonably well and be feature complete, and most <br>
vulnerabilities have now been fixed. My concern is that this legacy code has <br>
indirect costs on other GDAL developers and users. The psychological cost I <br>
mentionned. Let's say someone want to turn on higher warning levels, and that <br>
this breaks in tens of drivers. Would he have to ping every maintainer and <br>
wait for them to address the issue ? Or maybe he will just give up. Similarly <br>
for breaking changes in the driver API. As Sean mentionned, this is probably a <br>
serious obstacle to growing up the core development team.<br></blockquote><div><br></div><div>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.</div><div>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.</div><div><br></div><div>Regards,</div><div>Thomas</div></div></div>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>