search

rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
98.61k stars 12.74k forks source link

"Legacy" tier 2 targets have misplaced or absent maintainer docs #113739

Open workingjubilee opened 1 year ago

workingjubilee commented 1 year ago

Location

This affects our platform support documentation.

It specifically affects targets added before the target tier policy was confirmed, and especially those that are tier 2.

Summary

It is widely expected that the existing tier 1 targets are of primary concern for the Rust Project in general. As I understand it, the current absence of formally documented maintainers for them is based on the belief we have a large enough surplus of "target maintainers" for them that we can expect these targets to be effectively supported by "whoever picks up the slack".

However, tier 2 targets are trickier. Many are more niche, harder to find and run code on, and require specialized developer knowledge. These realities are part of why we expect targets to have target maintainers. Yet we have several without any documented support because they predate the target tier policy. This has recently led to us being forced to respond to exigent circumstances by interrupting our usual support because they implicitly violated the other side of the target support "contract": they impeded development of all the rest of our targets to a degree we cannot accept, with little other recourse.

This is a very bad situation. It is also a bad situation we can attempt to reduce recurrence of. Easily, in fact. Some of our targets have informally known target maintainers but we just... haven't written them down. Actually writing down who is invested in these targets in the same way other maintainers are listed would help reduce the need for guessing when responding in future high-priority situations where failure to act could stall-out work.

We should formally document target maintainers for the following tier 2 targets on the now-common platform support documentation pages. Technically this concern applies somewhat even to tier 3 targets as well but those should be handled in a separate issue as they are quite literally a separate priority level, and because tier 2 targets are unique in having potential to move to both tier 1 and tier 3. We may need to reduce our asserted support level for some of these targets. We also might like to raise our support level for others, without having to maintain our existing assumptions of having essentially infinite "slack" for them.

Tier 2 with Host Tools

Tier 2

thomcc commented 1 year ago

I can volunteer as a maintainer for at least these three.

It's worth noting that for many of these there's not a clean place in the documentation to mark a target maintainer.

workingjubilee commented 1 year ago

There is definitely a certain degree to which this issue is really about us needing to better organize our documentation and our "search for maintainers" is about finding our !s with our own two hands, given that we do have the ping groups, and the platform support docs, but it's... inconsistent. I started a T-compiler discussion on Zulip about this.

jonathanpallant commented 1 year ago

Related to this, I found a weird codegen issue on the thumbv7em-none-eabi and thumbv7em-none-eabihf targets when specifying -C target-cpu=xxx and I don't know who to ask about it.

apiraino commented 1 year ago

Issue discussed during weekly T-compiler triage meeting on Zulip (notes). Feels like this topic will need a separate discussion, possibly involving other teams. So, leaving nominated for now to figure that out.

jacobbramley commented 1 year ago

From this earlier comment (but continuing it here since that seems more appropriate):

I was under the impression that Arm Ltd were maintaining the thumbv*m-none-eabi* targets.

We (Arm) look at a few issues in that area, for example if we're tagged or if someone points them our way. However, we are not official maintainers of the embedded targets at the moment! That said, we care about them, so will be watching this with interest. Our day-to-day focus is aarch64-unknown-linux-gnu (tier 1), for which I think we are the official maintainers (though I couldn't find a list just now).

RalfJung commented 1 year ago

Can confirm -- I'm having some trouble with the sparc64 ABI and I'm not sure whom to ping either.

chrisnc commented 7 months ago

I've volunteered to maintain the Armv7-R targets (all four flavors). #110377 #119102 I could contribute to maintaining the Armv*-M targets as well, but I think those have a much bigger constituency and other informal maintainers.

jonathanpallant commented 7 months ago

The Embedded Devices WG had a PR cleaning up the docs and adding themselves to the Cortex-M targets, but it got lost. I'll try and open it again.

RalfJung commented 5 months ago

Would it be worth making some sort of blogpost, saying that we need people to volunteer as maintainers here and help write the docs for the target support page, or else targets will have to be downgraded to tier 3?

jonathanpallant commented 5 months ago

Seems reasonable. I gave all the Cortex-M targets to the EDWG so they can be ticked off.

chrisnc commented 5 months ago

The two "armebv7r-none-eabi(hf)? Bare Armv7-R, Big Endian" targets can be checked off as well.

RalfJung commented 5 months ago

Seems reasonable. I gave all the Cortex-M targets to the EDWG so they can be ticked off.

There is no target with "cortex-m" in its name or description so I'm afraid I don't know which targets you are talking about.

jonathanpallant commented 5 months ago

sigh, yeah, Arm naming is fun.

  1. See https://doc.rust-lang.org/nightly/rustc/platform-support/arm-none-eabi.html - it's not on stable yet
  2. I meant Arm M-Profile Architectures (which are implemented by a series of proprietary CPU cores sold to chip designers under the Arm Cortex-M branding):
RalfJung commented 5 months ago

Ah, I see, thanks.

It seems we do have target maintainers listed, but it's an email address, which doesn't work well with our usual github-based workflows. Any chance of having a github handle or notification group to ping?

jonathanpallant commented 5 months ago

Paging @adamgreig and @therealprof for that as I'm no longer in the WG.

workingjubilee commented 2 weeks ago

Nice, was able to mark off 15 targets as having any maintainer contacts, and a few more are en route.

rettichschnidi commented 2 weeks ago

Me (my employer) is interested in keeping armv5te-unknown-linux-gnueabi a Tier 2 platform. We should be able to invest resources (time, money), but we do not have any compiler experts. Please ping me if anyone out there is in a similar situation.

RalfJung commented 2 weeks ago

@uweigand mentioned they could be pinged for s390x related questions. @uweigand would you be willing to be listed as target maintainer?

FYI the definition of that role is

A tier 2 target must have a designated team of developers (the "target maintainers") available to consult on target-specific build-breaking issues, or if necessary to develop target-specific language or library implementation details. This team must have at least 2 developers.

Since we currently have 0 maintainers, I think we can make an exception to the "at least 2" rule and allow 1 to be listed (but this wouldn't be enough to get a checkbox in this issue). Maybe you know some people that would also be interested to help? :)

uweigand commented 2 weeks ago

@uweigand mentioned they could be pinged for s390x related questions. @uweigand would you be willing to be listed as target maintainer?

Yes, I'd be happy to take on that role.

FYI the definition of that role is

A tier 2 target must have a designated team of developers (the "target maintainers") available to consult on target-specific build-breaking issues, or if necessary to develop target-specific language or library implementation details. This team must have at least 2 developers.

Since we currently have 0 maintainers, I think we can make an exception to the "at least 2" rule and allow 1 to be listed (but this wouldn't be enough to get a checkbox in this issue). Maybe you know some people that would also be interested to help? :)

I'll ask around.

RalfJung commented 2 weeks ago

Yes, I'd be happy to take on that role.

Awesome. :)

@workingjubilee do you know how the paperwork for that works? :D

workingjubilee commented 2 weeks ago

@uweigand All that's required is to submit a PR adding the target's platform support document and noting that you do in fact assent to be the target maintainer in the PR description. There is a template here: https://github.com/rust-lang/rust/blob/759e07f063fb8e6306ff1bdaeb70af56a878b415/src/doc/rustc/src/platform-support/TEMPLATE.md

Make sure it's linked from the actual platform support page: https://github.com/rust-lang/rust/blob/759e07f063fb8e6306ff1bdaeb70af56a878b415/src/doc/rustc/src/platform-support.md

And listed in the summary: https://github.com/rust-lang/rust/blob/759e07f063fb8e6306ff1bdaeb70af56a878b415/src/doc/rustc/src/SUMMARY.md