- Adding unit tests to the old C code and continuous integration testing
- Auditing the C code with tools like ASAN, MSAN, Coverity, etc.
- Creating the beginnings a modern C++ library that is designed with testing from the start
- Starting a python utility library to facilitate creating tests for the C and C++ code
- Identifying files that would make the beginnings of a good test suite
- Show that history comments belongs in the revision history and changelog file, not the actual source code
- Start a list of issues with the code and show solving some of them
- Demonstrate payback to Leidos (formerly SAIC) for open sourcing GSF
At this point, I have put in quite a bit of time, squashed a lot of bugs, and set the stage for what I think the direction should be. However, looking at GSF in depth, it is clear that this is not a technology that the community should rely on. While the idea of GSF is great, it's fundamentally broken in many of the same ways as AIS that ESR and I identified in our toils paper. There are so many better technologies that could help build a format that was actually robust and capable for long term support of the community. For the good and the bad alternatives, see https://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats). I appreciate the people who helped get me. Evan Robertson went through the NGDC catalog and find files from older versions of GSF and Shannon Bryne at Leidos for the open sourcing process that took form 2008-2014.
There has not been any feedback from the community and no uptake of any of the code, with my goals met, it's time to hang it up. My hope is that eventually a group of people will pick up on GSF where I left off and finish off the fixes to the old C code and finish writing gsfxx and gsf-py. And beyond that, I hope yet more people will work on the same process for MB-System.
An incognito Google search to see if my github repo for GSF appears high on the list and it does: