[gdal-dev] Considering drivers removal ?
Jeff McKenna
jmckenna at gatewaygeomatics.com
Thu Jan 28 18:13:43 PST 2021
I'm also always surprised at how closely users follow the RFCs, what's
coming down the pipe, and the logic behind 'why' a driver or change was
implemented - this is always missing from regular 'official' user docs,
but users like to know why.
+1 for RFCs
-jeff
On 2021-01-28 6:54 p.m., Mateusz Loskot wrote:
> +1 for RFC
>
> Mateusz Loskot, mateusz at loskot.net <mailto:mateusz at loskot.net>
> (Sent from mobile, may suffer from top-posting)
>
> On Thu, 28 Jan 2021, 23:35 Kurt Schwehr, <schwehr at gmail.com
> <mailto:schwehr at gmail.com>> wrote:
>
> +1 for RFCs for new drivers.
>
> I took a couple minute run at what a template for the RFC might look
> like. It's painfully rough. Anyone wanting to edit the doc, let me
> know off list and I'll give you edit priv. Or make you own. You
> are welcome to take any or none of my draft text if you make your
> attempt at a template for a New Driver RFC. Should there even be a
> template?
>
> https://docs.google.com/document/d/e/2PACX-1vTtIU3WJw0APd7fXqfGVAYrBQGgURIzizb9MiXCI1trkj4PxOBZmz9o-Ne_5P7zkymM7dPjVZOCHBXl/pub
> <https://docs.google.com/document/d/e/2PACX-1vTtIU3WJw0APd7fXqfGVAYrBQGgURIzizb9MiXCI1trkj4PxOBZmz9o-Ne_5P7zkymM7dPjVZOCHBXl/pub>
>
> On Thu, Jan 28, 2021 at 1:37 PM Howard Butler <howard at hobu.co
> <mailto:howard at hobu.co>> wrote:
>
> 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 <mailto: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 <mailto:gdal-dev at lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>> <https://lists.osgeo.org/mailman/listinfo/gdal-dev>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
> <https://lists.osgeo.org/mailman/listinfo/gdal-dev>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
> <https://lists.osgeo.org/mailman/listinfo/gdal-dev>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
--
Jeff McKenna
GatewayGeo: MapServer Consulting and Training Services
co-founder of FOSS4G
http://gatewaygeo.com/
More information about the gdal-dev
mailing list