On 1/12/2021 5:36 PM, Even Rouault wrote:
On mardi 12 janvier 2021 12:56:13 CET Frank Warmerdam wrote:
On Tue, Jan 12, 2021 at 12:38 PM Howard Butler <how...@hobu.co> wrote:
The only question that matters here is "Who is going to maintain it?" and
if the answer to that is "no one", it should be removed. There doesn't
need
to be any meetings because the only criteria that matters is if someone is
willing to maintain it. We should provide the list of drivers and assign
the GitHub handles that step forward to be responsible for each. If
obscure
government one-offs formats have an audience of downtrodden government
users forced to use them, they need to put their handle in and take
ownership. They then need to find the time, money, or attention to carry
things forward.
Howard / Even,
I'd be willing to commit to maintaining some of the archaic drivers that
meet the conditions I mentioned (buildable, testable in core build). If
Even would like I can provide a sublist of those he proposed i'd be willing
to be responsible for.
NTv1: this is the perfect example of a driver of absolutely no use in 2021.
Unless I'm wrong, there was only one single public dataset for that format,
ntv1_can.dat, and it is now available as GeoTIFF in
https://github.com/OSGeo/PROJ-data/blob/master/ca_nrc/ca_nrc_ntv1_can.tif
My current plan is:
- for BPG, E00GRID, EPSILON, IGNFHeightASCIIGrid, ISG, Aeronav FAA, BNA, HTF,
OpenAir, SEG-P1, SEG-Y, SUA, X-Plane, move *now* driver code, documentation
and tests to https://github.com/OSGeo/gdal-extra-drivers which is a slightly
improved version of a cemetery repository, since it includes a build script to
create a plugin. I have no plan to maintain that repository after that initial
move (that means I won't merge pull requests unless someone else steps up for
the role) and it will likely break in the future. I'd wish we would agree to
move more drivers there. And probably most future drivers for esoteric formats
should go there.
Those drivers are ones I've authored, that received no significant
contribution from anyone else AFAIR, no-one paid development for and I suspect
are close to be unused. So hopefully no one should have bad feelings with them
going away. It was a bad taste of mine to have put them in GDAL to start with.
Why did I picked up the extra repository after all ? A tiny fraction of them
might be useful like ISG or IGNFHeightASCIIGrid in some contexts (to create
grids for PROJ), but definitely not for general purpose. So as far as I'm
concerned, I'll go through the extra step of building the extra repository or
a subset of it if I've an occasional need for them.
- proceed as I mentionned initially for other drivers I listed and no-one
steps up to maintain, with the variation of moving the code to gdal-extra-
drivers instead of just removing them (but potentially not including a build
recipee for them in the build script, if that proves to be too complex).
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.
Even
Even,
Just want to say this sounds like good plan to me, not that my input
means a lot. I also want to say Thank You! for all your hard work
supporting this and other projects, but answering my questions through
the years. I've had a lot of roles in my career in open source and
industry and can appreciate the difficult balance between compatibility
with legacy code and the need to break free of it to move forward. It's
hard and I never enjoyed having to make those decisions, but you have my
respect and support whatever you decide.
Thank You! again for your efforts and support!
-Steve W
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
