Maintainer of the libslink v2.8.x LTS branch

[yensoon2]

Good morning @chad-iris,

libslink 2020.048 suffers from (at least) the below two bugs:

Bug description	Impact of bug
The sl_collect() and sl_collect_nb_size() function implementations erroneously process incomplete SeedLink packets, due to mishandling the 8-byte discrepancy between SeedLink packet size (520 bytes) and miniSEED record size (512 bytes)	Segmentation fault on all platforms
The detect() function implementation can often erroneously perform unaligned memory accesses	Bus error on some platforms

Because you’ve already moved on to the libslink v3.x (i.e. “seedlinkv4”) branch, I can understand if you are reluctant to continue maintaining (e.g. fixing bugs in) the libslink v2.x (i.e. “develop”) branch.

Hence, I humbly propose that I become the maintainer of the libslink v2.8.x LTS branch. I’m willing and able to fork the libslink v2.x (i.e. “develop”) branch → the libslink v2.8.x LTS branch, then fix the above two bugs in the libslink v2.8.x LTS branch, then release libslink v2.8.0 LTS, and then fix any future bugs that are reported against libslink v2.8.x LTS.

This way, you can continue focusing on libslink v3.x, while I look after (the users of) libslink v2.x. My continued maintenance of the libslink v2.8.x LTS branch, will allow existing SeedLink clients to continue operating correctly, while giving these SeedLink clients time to adjust to the new libslink v3.x API.

If, for whatever reason, you wish to take back control of the libslink v2.x branch in the future, you can just release libslink v2.9.0. Everything in and from the libslink v2.8.x LTS branch will be superseded by your libslink v2.9.0.

Would you like me to become the maintainer of the libslink v2.8.x LTS branch?

[chad-earthscope]

Hello @yensoon2.

Thank you for your generous offer to be the maintainer of a v2 branch. I am hesitant, as I would like to promote the upgrade to the new version of the library (once it's released) for maintainers of libslink-based tools. The new version supports both the old and new protocols and important features such as new data formats. Put another way, the new major release will support a superset of what v2 supports and clients limited to the older protocol will slowly become obsolete when newer data formats and features of the protocol become expected; this is not what an "LTS" moniker implies outside of a close system of servers and clients.

The number of programs/environments that would benefit from new releases of v2 library is quite small I believe, most can (soon) spend the time porting to the new library for much more benefit. The port should not be very difficult for such maintainers.

I will consider this request further.

[yensoon2]

Good morning @chad-iris,

The number of programs/environments that would benefit from new releases of v2 library is quite small I believe …

I know of (at least) two organizations that need libslink to automatically determine miniSEED record lengths, without requiring source code changes to their SeedLink clients.

• They cannot use libslink v2.6 because libslink v2.6 cannot automatically determine miniSEED record lengths
• Their SeedLink clients currently link against libslink v2.7 (i.e. libslink 2020.048) but they encounter the bugs described above
• They cannot use libslink v3.0.0DEV because libslink v3.0.0DEV requires source code changes to their SeedLink clients

Hence, the only solution for them at the moment, is libslink v2.8.0.

So, coming back to this issue: How about I discard the “LTS” moniker from the libslink v2.8.x branch?

Friendly reminder that no work from you is needed here and if, “for whatever reason, you wish to take back control of the libslink v2.x branch in the future, you can just release libslink v2.9.0. Everything in and from the libslink v2.8.x … branch will be superseded by your libslink v2.9.0.”

If I discard the “LTS” moniker from the libslink v2.8.x branch, will you let me become the maintainer of the libslink v2.8.x branch?

[chad-earthscope]

Hi @yensoon2,

Thank you again for offering to maintain a legacy release branch and the rationale. I see the value of maintaining a 2.x branch and would be happy to have you assume maintainership. I would prefer not to have another repository contain the 2.x releases, I think that is confusing for users (obviously I cannot, and do not aim, to control forks). Unfortunately It does not appear to be possible to allow you to maintain only a branch.

I have created a 2.x branch and also tagged a 2.7.0RC release. This release includes automatic miniSEED record length detection and other fixes in the develop branch.

If it is acceptable to you, you can create pull requests to maintain the 2.x branch and I will trust that you have tested and do only minimal review before merging them. I would also like to agree on the following:

• The 2.x branch should continue to support the same platforms it does now (Windows, Unix/Linux, and macOS)
• No new features are introduced to the 2.x branch, definitely no features that the current release does not support, it is in a maintenance-only state

Is this a framework that works for you?

[yensoon2]

Good morning @chad-iris,

Thank you very much for your 2.x branch!

I’ll try to find some time (probably next month because I’m too busy this month, sorry for this) to check whether or not the above two bugs are still reproducible on your 2.x branch. Fixing bugs like these are minimal changes that neither affect supported platforms nor introduce any new features.

Then, if I have any pull requests, I will submit my pull requests against your 2.x branch.