Looking for new maintainers

[hannobraun]

Hey folks!

I intend to step down as the maintainer of this repository shortly. I'm off to new adventures and would like to be able to focus on this new direction going forward.

Unfortunately, I'm the only active maintainer here, so it's critical that we find someone to replace me. If anyone reading this is interested in becoming a maintainer, please post here or contact me privately, as you prefer. I'm also happy to stay on for a bit, to assist in the transition.

cc @mvertescher (original author of this crate, and the other member in the @stm32-rs/stm32f7 team)
cc @systec-ms (most active contributor recently)
cc @adamgreig (chief of stm32-rs)

[adamgreig]

Thanks for all your hard work here and good luck with Fornjot!

Hello, I am wondering if this might be a good way for me to "jump in the deep end" with embedded rust. I'm new to rust, but well experienced with embedded (see website). I started learning rust a couple of months ago, initially covering the basics on the desktop, and then to embedded. I have been working with the stm32f7xx-hal on a Nucleo-F767ZI.

Can you describe the HAL maintainer role and responsibilities, and the relationship to the embedded-rust wg and embedded-hal teams?

[hannobraun]

Hey @DarrylN, thank you for your interest!

Can you describe the HAL maintainer role and responsibilities

Well, there is no formal definition. I'd say, the maintainers most important job is to keep the project running, so it can keep being of use to people. Sometimes people run into limitations and submit a pull request to fix those limitations. In the absence of any factors that make that a bad idea, I think a maintainer's responsibility is to get that pull request merged, so that person can keep using the project.

I'm busy, and haven't been using this HAL myself for a long time. That gives me limited resources to fulfill that maintainer role, so I've been leaning heavily on contributors to make things work. I look over a pull request to see if anything jumps out as wrong (if so, I leave a comment). If I don't have time to check stuff against the reference manual, I ask the contributor how confident they are about their change. If I don't have time to test it, I ask how well they tested it.

If they express doubt in either of those, I slap on a help wanted tag, and leave a comment making it clear that we need help figuring this out. If later someone jumps in and says "this is okay", then I merge. If that doesn't happen for a while, I might still merge. Better to keep things moving. At least it works for that contributor, and if it breaks anything else, that can be fixed later. Hopefully whoever notices will open an issue (that you can tag with help wanted, if necessary) or open a pull request. Open source is for everyone, and by everyone.

If you have the wherewithal to do proper reviews and testing, maybe even develop a strong vision for where the project ought to go, all the better. Lots of maintainers are way more perfectionist than I am, but I think perfectionism is something you need to earn by being able to act on it (with reviews, testing, guidance, or fixing it yourself). If you can't do that, it's way better to keep things moving, than to let pull requests pile up for lack of resources.

Everyone can write code, review, test, and guide people to a proper solution. But your exclusive power as a maintainer is to press the "merge" button. That makes it the most important part of the job.

and the relationship to the embedded-rust wg and embedded-hal teams?

For me, very little these days. I used to be way more involved in the community, back when I did project work in the embedded Rust space for a living. I hang around the Rust Embedded and stm32-rs channels on Matrix. Following those to stay up to date would be ideal, but just being there so people can ping you, if there's a reason to, is already a good thing.

It certainly wouldn't hurt to follow a few key repositories (like rust-embedded/wg, embedded-hal, stm32-rs) on top of that, but it's not critical for being a maintainer here. If there's something that needs to happen here due to a change there, someone who cares can come over and submit an issue or pull request. Again, open source is for everyone, by everyone.

---

I hope my little essay here was helpful 😄

Let me know, if you have any more questions.

@hannobraun
@systec-ms

It's a very nice essay, and I appreciate the detail.

I'm looking into everything you mentioned, and it will be some days before I'm up to speed, but at this point, I'm intrigued. I ain't scared, but could be suffering from Dunning-Kruger haha. :-)

Meanwhile, questions...

• What proportion of issues here are caused by upstream changes (embedded-hal, stm32-rs, cortex-m) vs local bugs or feature adds?
• embedded-hal is currently at 1.0.0-alpha.6, who is doing gap analysis?

semi-related: where does probe-rs fit into the embedded rust ecosystem?

[hannobraun]

What proportion of issues here are caused by upstream changes (embedded-hal, stm32-rs, cortex-m) vs local bugs or feature adds?

Looking at the list of merged pull requests, the majority of changes are local. Upstream changes generally don't cause issues in this project, unless an upstream project (accidentally) ignores semantic versioning (or rather, the version of it implemented by Cargo). I can't remember when/if that last happened.

New upstream versions might cause issues for users, if they use this HAL together with other libraries that have already upgraded to newer versions. In the ideal case, that will result in that user submitting a pull request with a dependency upgrade here.

embedded-hal is currently at 1.0.0-alpha.6, who is doing gap analysis?

I'm not completely sure I understand what gap analysis means in this context, so please tell me, if my reply doesn't make sense. @systec-ms has started upgrading this HAL in #157. There's also some discussion in there about possible approaches.

where does probe-rs fit into the embedded rust ecosystem?

probe-rs is a critical piece of infrastructure that was readily adopted within the community as it became available, because everyone was really tired of OpenOCD. That this repository still contains OpenOCD configuration, but no configuration for cargo-embed (a probe-rs "frontend") or probe-run (a project based on probe-rs) speaks to the sub-optimal maintenance status of this repository.

If I had had the time to do actual development here, instead of just coordinating contributors, throwing out the OpenOCD/GDB config and replacing it with one of those other options would have been the first thing I did (as the mandatory prerequisite for whatever else I was going to do 😁).

[oyren]

@hannobraun thanks and also good success with Fornjot.
Sorry for my late reply (@systec-ms private account here), I've been thinking about whether or not to sign up as a new maintainer, but haven't come to a conclusion yet.

I'm interested, but not sure if I'm ready for it.
The next half year I will write my thesis, so my time will probably be limited. I made my previous contributions here during my internship semester. So my own development contributions will also be reduced and it will initially come down to me looking at PR and merging.
Also, I just started Rust 5 months ago.

I'm not completely sure I understand what gap analysis means in this context, so please tell me, if my reply doesn't make sense. @systec-ms has started upgrading this HAL in #157. There's also some discussion in there about possible approaches.

There is also stm32-rs/stm32f4xx-hal#388 from @burrbull, where you could certainly borrow some things ;).

By the way, if you would become a maintainer here, would you be part of the stm32-rs orginization or how would that work?

[burrbull]

Just for remind:
Main matrix group: https://matrix.to/#/#rust-embedded:matrix.org Meetings each Tuesday 19 UTC
stm32 matrix group: https://matrix.to/#/#stm32-rs:matrix.org

[hannobraun]

@hannobraun thanks and also good success with Fornjot.

Thank you!

I'm interested, but not sure if I'm ready for it.
The next half year I will write my thesis, so my time will probably be limited. I made my previous contributions here during my internship semester. So my own development contributions will also be reduced and it will initially come down to me looking at PR and merging.
Also, I just started Rust 5 months ago.

The decision is ultimately yours, of course. I would just recommend not to be intimidated by the role. As I explained above, I've been leaning heavily on contributors for a while now, and my successors doing the same would be a lot better than leaving the repository unmaintained.

Of course, the ideal maintainer would know the hardware inside out, develop a strong vision for the project, and work tirelessly to realize that vision. I've never been that ideal maintainer (at least around here, certainly tried in other projects 😁), and you wouldn't have to be either.

Most of what's required is the willingness to invest some time and focus. From a technical perspective, you're definitely ready (and given your recent experience working on this HAL, probably more so than me).

By the way, if you would become a maintainer here, would you be part of the stm32-rs orginization or how would that work?

Yes, you'd be invited to the stm32-rs organization (probably by @adamgreig; I don't think I can do that). By default, your membership would be private (at least I think that's how GitHub orgs still work), so you could choose if you want to be visible to non-members on the organization page.

In addition, Adam or me would add you the the @stm32-rs/stm32f7 team. That would give you all the technical access needed to maintain this repository and publish new versions of stm32f7xx-hal on crates.io.

stm32-rs is a very loose organization. There are no obligations for members that I'm aware of.

embedded-hal is currently at 1.0.0-alpha.6, who is doing gap analysis?
I'm not completely sure I understand what gap analysis means in this context, so please tell me,

'gap analysis' = tasks/effort required to meet the embedded-hal 1.0.0 spec.

@systec-ms has started upgrading this HAL in #157.

I agree with your comment about creating a branch for embedded-hal 1.0.0-alpha.

If I had had the time to do actual development here, instead of just coordinating contributors, throwing out the OpenOCD/GDB config and replacing it with one of those other options would have been the first thing I did (as the mandatory prerequisite for whatever else I was going to do grin).

Same. I almost got it working today. probe-run worked perfectly, whereas the vs code extension was able to flash but didn't seem to handle bp and stepping reliably. I asked for help on #probe-rs:matrix.org.

[maximeborges]

Hi,
I haven't had a lot of experience with Rust at the moment, and still struggling with some complex traits/macro stuff that we can find in those HALs, but definitely willing to learn more in the future.
Maybe having a few new maintainairs coming along at the same time could be nice, so they could discuss about the best solutions together will they get more confortable at the maintainer's job.
I could help with that, but wouldn't be very confident to do the job alone.

[hannobraun]

Hey folks!

Despite some interest, we haven't found a solution for my succession yet (is that the right word? makes me sound like some kind of king). Unfortunately, I'm really busy with Fornjot now, and I find it harder and harder to justify spending time to maintain a project that I haven't used in years.

Plus, given my lack of a test setup and deteriorating knowledge of the hardware, there's not much I can do anymore, except ask contributors how well-understood and well-tested their change is, and press merge if they give me the go-ahead. Anyone else can do that too, and anyone actually using the hardware can bring more expertise to the table than I can.

To force the issue, I'm stepping down as a maintainer effective immediately. I am happy to assist onboarding new maintainers, and I'll still take care of getting #167, #168, and #169 merged. Other than that, I won't do any more work here, except to point new contributors to this issue.

I will stay in @stm32-rs/stm32f7 for the time being, to ensure continuity on the technical/permissions side.