Le 31/01/2025 à 13:09, Paul Harwood a écrit :
The problem about "moving" the bindings is going to be that all of the SWIG definitions for all bindings are intimately wound together. It would be a lot of work for little gain.
That intertwine is both a strength and a weakness of our bindings, in that it apparently minimizes the level of effort to have them, but it results in bindings that are neither Pythonic, Javaish (or C#'ish ? no idea about how C# users feel about the GDAL ones), and that nobody really feels responsible about. The obvious illustration is that the casing convention one uses in the .i files for method and parameter names influences *all* bindings and obviously you can't expect all languages to agree on CamelCase, camelCase or snake_case ... Not to mention that in lots of case we just copy&paste the Hungarian convention from the C API that even most C users would dislike.
I know Howard has been a long time advocate of kicking all bindings out of OSGeo/GDAL and let them flourish or perish in their standalone existence (we just chatted yesterday about that again), and he's pretty happy with how that turned out for PDAL. But I'm also not so convinced that the return on investment is high enough for GDAL (contrary to the switch to CMake where there was a significant initial cost but I was convinced that it would be a big win, which it is), especially when selfishly thinking to the Python bindings, especially given their central place in libgdal testing.
NONE of these possibilities would be a valid response to our lack of knowledge.
You're right. I saw recently a toot from another OSS maintainer who also complained he had little clue about which part of his software were used, except when people filed bugs.
Options (readers: don't read all of them too literally and scream, just my current brain dump...):
- add on purpose bugs to the software to know which parts are used (at least the parts where you don't know) ?
- do nothing and let people feel demotivated/frustrated about maintaining the software and give up ? Only people who don't maintain code could naively assume there is a zero cost in keeping unused code around. The cost is hard to objectivize, but it is definitely not zero. If we had to pay for the VMs of our CI, there would be a clear cost in $$ for that. It also costs in term of time for maintainers when they develop and have to wait for a build to complete. Or when Coverity Scan, cppcheck, etc. have an upgrade in their analyzers that suddenly raise a new category of warnings. This is a sum of little something.
- wait that AI finally kick out human maintainers from the equation and can deal with an ever growing code base without complaining ?
- less provocative: add telemetry. obviously not opt-in because nobody would take the time to turn it on, but just opt-out
Even -- http://www.spatialys.com My software is free, but my time generally not. Grumpy maintainer. "De l'égo à l'égoût, il n'y a qu'une bouche mal refermée", André Isaac _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
