Create a Testing sub-team

[epage]

This RFC proposes creating a new sub-team for shepherding improvements to the end-user experience (wider Rust development community) for verifying their Rust code. For example, this team would be overseeing improvements to cargo test (owned by T-cargo under T-devtools) and libtest (owned by T-libs).

Rendered

[calebcartwright]

When I initially added this sibling team relationship I had RA and the rest of the editor/IDE landscape community in mind. However, I'm now remembering that RA is a separate team altogether, and I'm actually a little unclear on whether T-ides-and-editors is still a functionally active team?

Obviously the items captured in this list are not an exhaustive, binding list (we'll work with other teams as and when necessary regardless) but if anyone knows offhand whether this team makes sense and/or has thoughts on whether we should mention the RA team specifically that'd be good to know

[Manishearth]

it's not an active team, we should remove this and instead work with the r-a team here

[epage]

Seems like this is fairly uncontroversial. Added T-libs at Manish's suggestion.

@rfcbot fcp merge

[thomcc]

I think you have to be on one of the teams for RFCbot to work. (That or I'm about to make a fool out of myself)

@rfcbot fcp merge

[rfcbot]

Team member @thomcc has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @GuillaumeGomez
• @Manishearth
• @Xanewok
• @cuviper
• @ehuss
• @fitzgen
• @joshtriplett
• @kinnison
• @m-ou-se
• @oli-obk
• @the8472
• @thomcc

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[Manishearth]

(We're in the process of overhauling the devtools team membership; for now I have ticked the boxes of devtools team members who are no longer active: kinnison, Xanewok, and fitzgen)

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[Manishearth]

I would still like to see approval from @joshtriplett and @m-ou-se though, I would suggest not merging this RFC until they get around to seeing this.

[joshtriplett]

If this effort ultimately produces some new stable API surfaces (as I hope it does), it'll need to be T-libs-api.

[m-ou-se]

Exciting!

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[ehuss]

Thank you everyone!

@calebcartwright Can you follow up with a PR to https://github.com/rust-lang/team to create the team? Let me know if you have questions on what fields to add. Also consider adding a repo there if ya'll want to create one.

[calebcartwright]

Thank you everyone!

@calebcartwright Can you follow up with a PR to https://github.com/rust-lang/team to create the team? Let me know if you have questions on what fields to add. Also consider adding a repo there if ya'll want to create one.

Yup will do, already had some local changes in-flight for the r-l/team repo anyway

[chenyukang]

Will the test sub-team also take responsibility for cargo bench?
I noticed we almost forgot to stabilize benchmark testing:

• Pre-RFC: Stabilize `#[bench]`, `Bencher` and `black_box` - language design - Rust Internals
• When will benchmark testing be stable? - The Rust Programming Language Forum

[epage]

Now that we have the team, I expect we'll be laying out our plan. I personally expect benchmark support to be included as it is closely tied in with test support.

That said, I personally also see a lot of this being done by making custom test harnesses a first class citizen and doing the work on most of this outside of libtest