Maintenance and Roadmap

[fschrempf]

This is a nice project and it would be great to see it moving forward. Thanks @doceme for your work and especially for merging some of the PRs recently.

Anyway I would still like to ask if there is any further interest in getting some cleanup and maintenance work done and make this module ready for the future. 😉

It seems like in the past @Gadgetoid has done quite a bit of work and also offered to maintain it. Is this offer still valid today?

@doceme Would you accept other maintainers or co-maintainers?

Some things that would be nice to do IMHO:

• Drop legacy code (Standardise on one approach to numeric parsing, drop Long support from Python 2.x #98)
• Support recent kernel mode flags (Support 32-bit mode flags and SPI_MOSI_IDLE_LOW #141)
• Triage open issues
• Add unit tests (Standardise on one approach to numeric parsing, drop Long support from Python 2.x #98)
• Add CI integration

I would really like to hear from you and looking forward to discuss this with you. Thanks!

[doceme]

Thanks @fschrempf for your interest in the project and recent pull request. Community involvement is what keeps projects like this alive.

I am definitely interested in any changes that would make this project work better for everyone, like unit tests, CI integration, etc. As far as changes that break compatibility with older kernels, I am also open to those as well, but it would be nice to hear thoughts from other people that use the project.

For the 32-bit mode flags one, specifically, I would personally be okay dropping support for really old kernel versions. Otherwise, there are certain features that we would never be able to add. If someone really needs support for those old kernels, they can always fork the project.

I would be happy to have help maintaining the project.

[fschrempf]

Thanks @doceme for the fast response. Sounds great. Let's see who else might want to comment.

If you feel comfortable with me doing so, I could offer to go trough the open issues, adding a few basic labels, closing some that aren't relevant anymore, etc. If not at this point, that's also fine.

[Gadgetoid]

It seems like in the past @Gadgetoid has done quite a bit of work and also offered to maintain it. Is this offer still valid today?

At the moment, no. My attention is currently focussed elsewhere (Raspberry Pi Pico and MicroPython) so I don't have the hands-on experience I did when I first worked with spidev. I would, I expect, be a liability 😆

[yochem]

Other future improvements to consider:

• Modernize packaging (pyproject.toml, (partially) remove setup.py, setup.cfg, MANIFEST.in)
• CI/contributing: lint and check format on PRs, publish package on tags etc, generate docs
• docs: autogenerate from docstrings on each commit to master. The docs can be hosted on github pages, or, because of the small interface, it can be included in the README (as is the case currently).