Last week the entire team went on our seasonal retreat, this time in the german country side. During that week the engineering crew came together to identify common pain points and cross-cutting concerns we want address:
- Change discourse and proposal process
- Shared infra/CI
- Rust: errors
- Rust: concurrency
- Rust: WASM macros / build times / local dev
- hardware budget and guidelines
champions: Fintan, xla
We want to establish ways as a team to propose and discuss changes, capture potential outcomes and establish shared best practices. Examples for that are vividly captured in the topics above. What we settled on, with added benefit of becoming more open, is to move our engineering/dev discussions to our public forum on: community.radworks.org. Once an idea has been brewing to the point where it’s worth proposing in a form of an RFC/ADR or similar format we want to make it permanent in a central place. For that we bootstrapped the GitHub - radicle-dev/radicle-decisions: Radicle Developers of All Countries, Unite! repository, how the process is going to look in detail will be figured out and more to come on that front this week.
We got some big challenges ahead of us including publish/release processes, guide and participate in public networks of our protocols, tame CI and other common tooling of our dev pipelines. While partly addressed with the opening of a devops position we still need alignment for our expectations and see how we can distribute the responsibility.
Errors are often at the core of the way we do control flow esp. when consuming client libraries of the protocols. There is some fancy, shiny tooling out there which makes it more manageable to create good error infrastructure. Objective here is to find out if there is a common way we can settle on, what the benefits are and what good error handling should look like in Radicle Rust projects.
While fragmented and developing at a fast pace, we ought to assess if we can standardize on a sane set of crates and runtimes. It already has been an ongoing effort to deal with libs that offer async APIs and the crates we depend on also make progress in that direction. Ideally we find something that a developer can pick up when implementing or dealing with async APIs.
Our build times have been a huge pain point in most parts of our dev lifecycle, from local to CI. We want to investigate if there are ways to shorten our feedback cycles. As some of our dependencies are very
macro heavy, we want to research into that direction and also evaluate extra approaches like cargo remote.
With the more demanding requirements to our dev setups and the ability for people to autonomously decide what the best and most comfortable work tooling is, we want to evaluate if the current budget is sufficient. And prepare recommendations and helping guides of what configurations make sense, so this research doesn’t need to be done on an individual basis.
This sums it up for now, please add where I missed a point and follow up with questions you have. Definitely going to append with updates in this thread as soon as we have further developments to share.