Hi Sean, I would also be supportive to formalize the driver submission process.
Best regards, Tamas Sean Gillies <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> > 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> 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.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 >>>> >>> > -- > Sean Gillies >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
