Looking for Maintainer

[niondir]

The project was created in the urge of using Rust for our embedded development and was a first proof of concept. Unfortunately the real world makes it much harder to migrate to rust than I would like. That's the reason why we do not use the library in production yet.

On the other side I see a lot of interest in moving the code forward and welcome this a lot. I just feel too inactive on GitHub to maintain the project alone with the Quality it deserves.

If there is someone who like to help maintaining the library I'm open for suggestions.

@schteve I just merged a lot of PR from you. If you have long term interest to use and develop the library, just let me know. @reitermarkus same holds for you.

[schteve]

First I'd like to say thanks for your work in maintaining the project to this point. I can see a lot of effort went into it and it's already quite useful as-is.

I'd be happy to help with maintaining the project, but what kind of maintenance help did you have in mind? Approving PR's? Making contributions and shaping the direction of the project? Taking some type of ownership? I could do any of these, I think. It would also help to understand what your long-term expectations are for the project.

I don't have immediate plans to use this crate in production either (right now just some basic hobby stuff), but have been happy to use FreeRTOS for many years in production with C on embedded systems, so I'd like to see it succeed here with Rust as well. I'm most familiar with V9 and earlier so I have some catching up to do with V10 and beyond.

[niondir]

Hey, thanks for your reply. Your questions make sense I want to give some answers to them.

what kind of maintenance help did you have in mind? Approving PR's? First of all reviewing and approving PR's and answering new issues.

Making contributions and shaping the direction of the project? Contributions are welcome. But I can't expect too much - since it's all free work. I'm happy about any help.

Taking some type of ownership? I don't really expect that.

It would also help to understand what your long-term expectations are for the project. I guess a long term goal is to stay feature complete regarding the FreeRTOS API and providing a easy to use interface. In addition try to support as many platforms as possible or needed.

For me (or us at Lobaro) the long term goal is to have an easy to intergrate solution to our existing FreeRTOS based code to migrate to RUST. Which I can't say when it will happen.

Let me know how you would see your role on this project.

[housel]

I am using this crate in production, and will continue to watch new issues and PRs, and contribute comments if I have anything to add.

After the recent round of accepted PRs I think it would be nice if there were new tagged releases on crates.io.

[schteve]

Thanks for your answers. It sounds like the main help you're looking for is on the PR / issue side. I'd be happy to help there, and I think your long term goal of makes sense and should be enough to guide future decisions. I think the project doesn't get a huge number of contributions so it should be quite manageable.

[schteve]

On the contribution side, in making my recent commits I did notice a few things that I could do. I didn't want to start them if these changes aren't welcome though. Let me know what you would be interested in.

• rustfmt - currently code formatting does not strictly comply with rustfmt. I think it's pretty typical for a project to require this. Should be pretty easy to run rustfmt to fix the code and then double check it manually.
• cargo test - I noticed some errors / failures are generated when running cargo test. Not sure if it's something on my end, but all existing tests should run and pass if possible.
• Test coverage - There is probably some opportunity to increase test coverage by writing new test cases. Whether those are unit tests or integration tests (maybe even some that execute on embedded hardware?).
• cargo clippy turns up a number of warnings. I think it makes sense to eliminate all of these warnings (either through code changes or suppression). Also to investigate the same with clippy::pedantic, but this isn't as likely to be helpful.
• CI scripts - run these via Github actions on new commits and merges. Enforce build success (including examples), formatting, tests, and clippy lints.

Let me know what you think. Especially if I'm going to help as a maintainer it will be good for me to have a deeper understanding of the codebase, and making the above changes would be good tasks to help me learn.

[schteve]

@niondir let me know if you have an opinion about the above contributions

[niondir]

Sounds all very reasonable. That's a good base to let the project grow in a clean way.

[schteve]

Thanks @niondir, I'll get going on those points then. Probably CI scripts first since we've had a few accidental breakages recently that would have been avoided if CI was checking the build.

One other topic that comes up occasionally - publishing new versions to crates.io. I know you don't have time to watch this closely so what would be the best way to coordinate a publish schedule? If you're willing to give me rights to do the publish I can publish periodically as we accumulate changes. But the crates.io publish system might not make that easy for you (not sure how exactly that works).

[sheref-sidarous]

Hello, I'm an embedded SW engineer by profession who is interested in Rust and what it can do for the future Embedded Software. I'd like be more involved with Rust ecosystem therefore I'd like to help maintaining this project. I don't think I can yet be the primary maintainer but I'm glad to help.