[gdal-dev] GDAL sponsored maintenance report: Aug 2021-March 2023

[Even Rouault]

Hi,


After more than one year and a half of benefiting from the GDAL 
sponsored maintenance program, it is time to share with the community 
what work has been accomplished thanks to that sponsorship.  It is quite 
hard to summarize, as the amount of tasks reaches 1800 for a total of 
1313 hours. So lots of small tasks that make the daily reality of 
maintaining a project like GDAL.


Their global repartition is the following one:

  *

    Bug fixing: 51% of actions, 55% of time spent (including 177 bug
    fixes related to issues found by oss-fuzz)

  *

    Enhancements: 5% of actions, 15% of time spent

  *

    CMake related work: 5% of actions, 10% of time spent

  *

    Review of contributions: 20% of actions, 5% of time spent

  *

    Release management: 2% of actions, 4% of time spent

  *

    Bug triaging and analysis (without corresponding bug fix): 8% of
    actions, 3% of time spent

  *

    Maintenance of continuous integration setup: 3% of actions and time
    spent

  *

    Code enhancements/cleanups: 2% of actions and time spent

  *

    Documentation: 1% of actions and time spent

  *

    Other activities: mailing list discussions, bug reports to other
    projects, meetings, etc.


This work has benefited mostly to GDAL (80%), PROJ (15%), libtiff (2%), 
openjpeg (1%) and more marginally to other projects associated with GDAL 
such as Xerces-C, poppler, libgeotiff, cppcheck, netcdf, curl, libjxl 
and shapelib.


The CMake related work has been a major item of work for the mid 2021 - 
beginning of 2022 period. I cannot overstate the importance of the 
initial contribution of this work made by Hiroshi Miura who brought most 
of the initial material. That said, without the sponsored maintenance 
program which helped polishing and making it production ready for all 
environments supported by GDAL, this would likely have remained a 
out-of-tree project. I believe most stakeholders (contributors and 
users, at least the ones who build from source) are very satisfied with 
this transition from the historic build systems to a unified and more 
modern one, with consistent option naming. Building on Windows is in 
particular much easier nowadays, in particular when leveraging 
dependencies from distributions like vcpkg or Conda Forge. For GDAL 
developers, the new build system offers integration with IDEs and solves 
long standing annoyances like missing header dependency rules for 
partial rebuilds.


Although it doesn’t show up particularly in the above statistics, making 
sure that the continuous integration configurations remain “green” at 
all times is a constant source of attention. Given the number of 
environments tested and the number of dependencies of GDAL, there is 
hardly a week where some action is not needed in that area to make sure 
that the code builds and compiles cleanly, tests pass, etc. We can now 
track a few rolling distributions to detect as early as possible sources 
of incompatibilities with our dependencies, and act early: report issues 
to upstream if there are bugs, or do changes in our code & build scripts 
to take them into account.


Making sure that code contributions from others are reviewed in a timely 
manner is important for the contributor experience. The average delay 
for a submitted pull request (excluding mine) to be commented by me (or 
merged if no comment needed) is 22 hours, and the median time 3h20 
(statistics gathered on 601 pull requests since August 2021, source 
script at https://gist.github.com/rouault/0fbd37f59b8e93ae63761468a5600262)


In the category of regular tasks, one can also mention: updating the 
EPSG dataset in PROJ (and coordinating with IOGP when detecting issues), 
refreshing vendored of copies in the GDAL source tree (libtiff 
typically), making sure that new SQLite releases play nicely with PROJ 
which has some stressing SQL queries (we spot recently a performance 
regression in SQLite 3.41.0 and reported it to upstream)


The following RFCs have been implemented (not mentioning a few 
procedural ones) thanks to the sponsorship:

  *

    RFC 87: Signed int8 data type for raster
    <https://gdal.org/development/rfc/rfc87_signed_int8.html>

  *

    RFC 88: Use GoogleTest framework for C/C++ unit tests
    <https://gdal.org/development/rfc/rfc88_googletest.html>

  *

    RFC 90: Direct access to compressed raster data
    <https://gdal.org/development/rfc/rfc90_read_compressed_data.html>

  *

    RFC 91: GDALDataset::Close() method
    <https://gdal.org/development/rfc/rfc91_dataset_close.html>

  *

    RFC 93: OGRLayer::UpdateFeature() method
    <https://gdal.org/development/rfc/rfc93_update_feature.html>


Other recent significant work includes enhancements in Python exception 
handling (in preparation for enabling them by default in a future 4.0 
release), and enabling them in the regression test suite and utilities.


The following feature releases have been issued: 3.4.0, 3.5.0 and 3.6.0. 
And the following bug fixes releases: 3.3.2, 3.3.3, 3.4.1, 3.4.2, 3.4.3, 
3.5.1, 3.5.2, 3.6.1, 3.6.2 and 3.6.3

Best regards,

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230327/0299c1eb/attachment.htm>