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 <szeker...@gmail.com> wrote: > > Hi Sean, > > I would also be supportive to formalize the driver submission process. > > Best regards, > > Tamas > > > Sean Gillies <s...@mapbox.com <mailto:s...@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 <szeker...@gmail.com > <mailto:szeker...@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.broch...@gmail.com <mailto:david.broch...@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.bonf...@gmail.com > <mailto:thomas.bonf...@gmail.com>> wrote: > > > On Tue, Jan 12, 2021 at 11:36 PM Even Rouault <even.roua...@spatialys.com > <mailto: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 > > -- > Sean Gillies > _______________________________________________ > 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
