[RFC] rust-embedded teams and maintenance of the embedded ecosystem

[japaric]

closes #46

Rendered.

RFCs for creating each team

• MSP430 team #137
• RISCV team #138
• embedded Linux team #139
• resources team #140
• tools team #141
• HAL team #142
• Cortex-M team #143
• triage team #144

[korken89]

Hi, I think painic_abort is missing in cortex-m team, or maybe it is excluded for a reason?

[japaric]

@korken89 panic_abort is not Cortex-M specific. It also doesn't compile on stable because of intrinsics::abort, which doesn't have a path for stabilization.

OTOH, panic-itm is in there because ITM is Cortex-M specific, panic-semihosting is in there because it only supports the Cortex(-M) at the moment.

[japaric]

The RFC has been updated with the input from today's WG meeting. The section on the initial composition of the teams has been removed -- in its place we'll have one RFC PR per team -- to reduce the volume of comments in this thread.

cc @TeXitoi @korken89 @levex @ithinuel @kellerkindt

[japaric]

I have created follow up RFC PRs to form the initial teams:

• MSP430 team #137
• RISCV team #138
• embedded Linux team #139
• resources team #140
• tools team #141
• HAL team #142
• Cortex-M team #143
• triage team #144

There was consensus on accepting this RFC in today's meeting. So we are going to put this RFC into a one week final comment period and then proceed to merge it if there are no unresolved concerns by then.

It would be great to have consensus on the initial team RFCs by next week so we can start implementing this RFC next week. So please take a look at the RFC PRs.

[jamesmunns]

@japaric one item I didn't see explicitly mentioned is who makes up the rust-embedded/wg team. Do we retain the current roster, would this be reduced to just you, or made up of the leads of each of the sub team/projects?

It would also be good to state how the wg team fits in to the other projects in the new organization.

[hannobraun]

Looks good to me!

[hannobraun]

Looks good to me!

[japaric]

@jamesmunns In my mind, the WG is the union of all its teams. When it comes to voting on cross cutting concerns I would say that all the relevant teams get to vote, and everyone in the community can give input and raise concerns.

The people in the current roster will become (remain) members of the rust-embedded org, even if they are not in a team right now -- for example, there's no RFC for an avr team atm.

Also, at least a member of each team should attend the weekly meetings to give an update on the work of their team.

We should write a complimentary RFC on the role of this repository and how meetings are run.

[jamesmunns]

Rough status of the vote so far:

• @dvc94ch
• @dylanmckay
• @hannobraun
• @jamesmunns
• @japaric
• @jcsoo
• @pftbest
• @thejpster

[japaric]

I found that the triage procedure used in rust-lang/rust is documented in the forge so I have updated to RFC to replace my guesstimated instructions with a link to the instructions in the forge.

[ryankurte]

Are we going to have a separate team for infrastructure / ops (looking after domains/DNS/websites/blogs/etc.) or would that fall within the resources team?

[jamesmunns]

Hey @ryankurte, I think that would fall to the resources group, though on #148 I am pushing for as few self-managed options as possible.

This would leave ownership pretty much with the contributors to the individual repos in the organization (for content and CI).

@nastevens currently controls the DNS for the rust-embedded domain, so we would need to work with him on how to manage this.

[japaric]

@ryankurte We discussed this on today's meeting and decided we'll revisit the creation of an ops team after we have a decision on RFC #148 (Community plan).

As there are no unresolved concerns here, or leftover from the meetings, and there's voting majority I'm going to merge this RFC and make it effective. Thanks everyone for your input here and on IRC.

[japaric]

It was pretty boring but I have made this RFC effective. All the initial members of the teams should have received an invitation by now.

For posteriority, these are the changes I had to made to each repository:

• travis-ci.org

  • Enable "Build pushed pull requests"

• Code

  • add .github/CODEOWNERS
  • add CODE_OF_CONDUCT.md
  • .travis.yml
    • add master to the branches to test (required to get PR builds working)
    • add if to matrix.include (prevents testing merged PRs again)
  • tweak bors.toml to reject r+ if the PR has not been yet approved
  • update README to mention which team maintains the repo and the code of conduct

• bors settings

  • give access to users with write permissions to the repo

• GH settings

  • team has admin permissions
  • protect the master branch

Example: rust-embedded/cortex-m-semihosting@c237143

[japaric]

One more comment: all team members now have "bors rights" and can send PRs to bors using "bors r+" (not "@bors r+"; we are using https://bors.tech, not the rust-lang instance). You can find documentation about the bors commands in https://bors.tech/documentation/

cc @rust-embedded/all

[japaric]

Another update: all team members should now have publish / yank permissions on crates.io. One thing I didn't realize until it was too late is that team members can not add or remove owners. I realized this after I removed myself as an owner on most Cortex-M crates so now all those crates are owned by a single team and no more owners can be added. Which is not too bad except that, for example, the itm crate only owner is the cortex-m team but it was supposed that the tools team would also be an owner of that crate -- that can't be done anymore: the cortex-m team members can't add the tools team as an owner.

If this turns out to be a problem in the future we can always bribe ask someone on the crates.io team to add a user owner to these crates where the only owner is a team.

TL;DR @pftbest @dvc94ch on crates.io add team owners to your crates but don't remove yourselves from the owner lists. Always keep a user owner so they can modify the owner list in the future.