[gdal-dev] Killing useless write side of drivers

[Even Rouault]

Andrew,

| one might think that the purpose of GDAL was to allow conversion 
between geospatial data formats.

The ones that are still of use for someone

>
> I would prefer it if that was extended to include other purposes,
> rather than actually removing that as a significant purpose of GDAL.
Sorry, I haven't understood what you suggest exactly.
> I note that this email has already provoked the removal
> of one *read-only* driver - https://github.com/OSGeo/gdal/pull/11684

We don't remove drivers that have an evidence of being used, just the 
ones that we strongly suspect that they are not or very little used. 
This is no different than GCC killing obsolete architectures or the 
Linux kernel removing unused or *unmaintained* drivers or architectures. 
Contrary to those projects, the vast majority of GDAL drivers don't have 
active maintainers to baby sit them. So if users don't speak up and 
maintainers don't show up, we are reduced to guessing, and obviously we 
can be wrong in our guessing, so be it. The only way of being sure would 
be to have some telemetry, but obviously we aren't going to do that. 
Some drivers have been written 25 years ago for interoperability with 
software that might not be around anymore, or for users that have moved 
to something else. Current maintainer team has no experience with most 
of those formats. A number of the obscure ones might not have any unit 
test. For example, yesterday, following my RFC105 changes, I fixed an 
oss-fuzz discovered regression I caused in the JAXAPalsar driver. So I 
was: "ok, let's run the unit tests. Oh wait, there is none!" So this 
driver might work, or not. All those drivers also increase the 
vulnerability surface of the project, increase compilation time which is 
a pain for developers, etc, so there's a lot of reasons to do clean ups.

>
> If we are going to be more selective in which data fromats we support,
> what can we do to make easier to build out-of-tree drivers as plugins ?
>
> For example could github build gdal packages which other, third-party, 
> github projects could pull in as a base to build these ?

Sorry, didn't get what you meant. I believe building out of tree drivers 
for GDAL is reasonably easy.

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.
Butcher of all kinds of standards, open or closed formats. At the end, this is just about bytes.