RFC: Move to atsamd-rs organization

[wez]

I think there are enough folks contributing to enough boards that this makes sense to do, and it should streamline progress. We recently went through a similar process for the nrf-rs family of boards.

Here's what I'm proposing:

• I'll create the organization and move this repo into it, so that it ends up being named something like atsamd-rs/atsamd (I've omitted the 21 because I have an atsamd51 that I think we can support with basically the same HAL).
• I'll create a github team for the purpose of owning the crates on crates.io, with members comprising the folks that contributed the boards and published to crates.io
• We each add that team as an owner of the various crates which we have access, so that any of us are now able to push to the repo (but see below!) and publish to crates.io
• Members of the team will need to enable 2FAC for their github account; this will be enforced through githubs existing controls such that github will automatically remove you from the team if 2FAC is disabled.

While we'll all have the ability to push, I'd like to encourage the use of pull requests to solicit input and feedback before unilaterally pushing. I'm generally in favor of making forward progress, so if you do have push access and haven't had feedback within a reasonable time, or if in your best judgement the change you want to push is non-controversial and/or low risk, then I think it's fine to push. As a reviewer, if you'd like to have a chance to weigh in but don't currently have time then communicating that and a rough ETA on the pull request is a good idea.

Thoughts? Concerns?

@zklapow @djmcgill @BenBergman @sajattack @bfritz

[sajattack]

Would it be good to split the board crates out into different repos in the org?

[wez]

Would it be good to split the board crates out into different repos in the org?

No, and yes :) I'm a proponent of the monorepo concept, where the related projects live in the same repo rather than being separate repos. There are some nice benefits from doing this:

1. It is possible to atomically refactor across all of the related projects in a single commit, and more importantly, to atomically roll back a change in a single commit
2. Github has no support for dependent, cross-repo pull requests, making it difficult to compose, review, run CI and ship a change that touches multiple areas, so having a single repo means that we sidestep this issue; pull requests that make changes to the hal need to be accompanied by the corresponding changes to the board support crates in order for the CI to pass which reduces the chances of accidentally breaking a board crate that you haven't directly changed.

A potential downside of this is that updating a lot of board support crates becomes burdensome. I think we're still in a reasonable place given the current set of board crates, especially since they are all very similar. I am prepared to spill things out of the main repo should it start to feel painful, but will likely keep a couple of boards in the repo because of point 2 above.

[BenBergman]

I'm generally against mono-repos, but I think it makes sense in this instance where everything needs to update together or it might not make sense. Semver definitely helps the split repos work better, but I don't think it is needed just yet.

As for encouraging PRs, make sure contribution guidelines are written down somewhere and at least referenced in the main readme. It might be possible for GitHub to require code changes come in through PRs (I've done this in other Git servers but haven't needed to in GitHub yet). Even if it is one of those simple changes that shouldn't affect anyone, having that easily navigable history showing which commits were part of a change might be nice to have.

[zklapow]

👍 I am very much a fan of the organization move, I think it makes a lot of sense as the number of contributors grows.

Also agree re: monorepo. The BSP crates are suvh thin facades at this point that I really dont think they deserve their own repos, and having the ability to do a full refactor across them is well worth it.

[djmcgill]

Sounds good to me

[wez]

OK, I've moved the repo and sent invites. I'll come back and look at the permissions/access stuff a bit later.

[sajattack]

@wez I see you kept the project named atsamd21-rs. Are you planning to separate out the 51 now or just haven't renamed yet? I have a Metro M4 coming and I'd like to know the appropriate place to add support.

Also, do you want me to bring over uf2conv-rs? It's more of an Adafruit/Microsoft-specific thing than an atsamd thing.

[wez]

@wez I see you kept the project named atsamd21-rs. Are you planning to separate out the 51 now or just haven't renamed yet? I have a Metro M4 coming and I'd like to know the appropriate place to add support.

Thanks for noticing; yeah, I hadn't gotten around to it. I just renamed it. We can figure out the specifics for the 51 in a separate thread/issue.

Also, do you want me to bring over uf2conv-rs? It's more of an Adafruit/Microsoft-specific thing than an atsamd thing.

In the long run it's probably better off elsewhere, but I'm not opposed to it living in the same GH org for the time being, especially if we end up having something nicely integrated for flashing the code from cargo.

I know that @tannewt is interested in seeing M4, UF2 and Rust all come together.

[sajattack]

We did this a while back so I'mma close this issue.