Looking for a new maintainer or release manager

[SpotlightKid]

Hi all, the last months have shown that I currently neither have the time nor the motivation to give this project the attention it needs and deserves.

I am therefor looking for someone, who is willing to take over maintainership of this project or at least act as a release manager to get a much needed update released soon.

If you are interested, please reply here or contact me personally via email at info@chrisarndt.de

[rec]

Thanks for all your work on this library!

---

I do not have time to take over maintainership on my own, and I can only do MacOS builds for the immediate future.

That said, I'd be willing to handle the MacOS builds and also help with code reviewing and bug fixing, if you had another active maintainer who could do Windows and *nix builds.

---

You might consider contacting the guy behind this: https://github.com/mido/mido/ or hitting up computer music forums or subreddits, or maybe hitting up academics somehow.

This program is important to anyone doing Python and MIDI. I think once the ball was rolling, there would be enough interest that you could easily step away.

Thanks again!

[rec]

(I mean, I could fire up a cloud machine or a docker and run a *nix build pretty easily, but the issue would be testing it...)

[Czaki]

I could resetup cibuildwheel for the build wheel on GHA if there will be such a will from the new maintainer. My current usage is only really simple MIDI controllers so I do not have enough context for maintenance.

[SpotlightKid]

@rec @Czaki There is already a pull request (#119) and the accompanying branch feat/modernize, which sets up GH actions to build python-rtmidi for *nix, macOS and Windows, and another PR (#121), which fixes the cibuildwheel build of the former PR (I believe, haven't tested that PR yet).

So what remains to done for a new release is intergrating these PRs and making sure the resulting packages work on at targets OSes.

[Czaki]

@SpotlightKid There is also #100 that is earlier that pointed PR and to which one I point that I could redo it using recent cibuildwheel.

[SpotlightKid]

#119 changes the project structure significantly. #100 would probably need to be updated in a major way to accomodate.

[Czaki]

ok, In the context of #119, the #100 looks obsolete. The most important part is already in #119. If you have any problem with cibuildwheel in #119 I could help.

Should I close #100?

[SpotlightKid]

Should I close #100?

Yes, that's probably the best. Sorry that I didn't really follow up on that. But, if it's any consolation, I used it as a reference when working on #119.

If you have any problem with cibuildwheel in #119 I could help.

The reason I did not merge that yet is that there were problems with the *nix builds, IIRC. It's been a while... The details should be in the GH actions build logs. As I said, #121 might already fix this.

[Czaki]

Logs were expired. And such information that persists show a problem with windows, not unix (UNIX jobs were canceled because of failure of windows action, that is, default GHA behavior that could be changed by set fail-fast: false.

[SpotlightKid]

Ok, I probably remembered that wrong.

I just rebased the branch and triggered a new build.

[brunoenten]

Hi @SpotlightKid, I'd gladly take charge of the maintenance until someone better suited comes along.

[SpotlightKid]

@brunoenten Thanks for your offer. Can you please contact me at the email address mentioned in the description and give me a short outline what your next steps for the project would be? Just so I know that you won't turn it into a closed-source, windows-only software ;)

Afterwards I can give you access to the Github project and the PyPI entry.