From 680adfef08afa1f1935b9a83ea36045ab3c610b0 Mon Sep 17 00:00:00 2001 From: Katharina Fey Date: Mon, 4 Nov 2019 15:53:11 +0100 Subject: Adding note about shepherds and fixing markup --- content/blog/111_rust_2020.md | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/content/blog/111_rust_2020.md b/content/blog/111_rust_2020.md index e2b8645..9dc3514 100644 --- a/content/blog/111_rust_2020.md +++ b/content/blog/111_rust_2020.md @@ -109,13 +109,19 @@ to them how regular) meetings discussing the wider implications, as well as small details of an RFC, usually on a video call, taking notes for people who can't attend to read up on afterwards. +**An important note here:** shepherds don't have to be part of a team that +would otherwise oversee the development of a feature (like lang or +compiler) and instead can be any community member who feels like +nominating themselves or who is nominated by someone else. The idea is +that *everybody* should be involved in overseeing incoming RFCs. + ## Governance WG and a new process Generally, I think we all know that the RFC process needs to change. It has a bunch of problems that have lead to people physically and mentally burning out while contributing to Rust. And, as XAMPPRocky mentioned in her post, sustainability is important for Rust -to remain a healthy project, 5 or 10 years down the line. +to remain a healthy project, 5, 10 or 15 years down the line. I haven't followed a lot of progress from the governance workinggroup, but reading their charter and some of the proposed [RFC stages][gov] @@ -138,13 +144,13 @@ RFC on changing the RFC process in the ways that I propose in this post, there's some personal projects I want to get going as well. At the beginning of the year I told myself that my SQL migration crate -`barrel` would see a `1.0` release by the end of the year. This is +`barrel` would see a 1.0 release by the end of the year. This is looking less and less likely, but I want to at least get close to -it. And then, next year, there will be a `1.0`. There's a bunch of +it. And then, next year, there will be a 1.0. There's a bunch of improvements to the crate itself, as well as compatibility with other -crates (such as `diesel` and other migration toolkits), I want to make. +crates (such as diesel and other migration toolkits), I want to make. -There's `clap 3.0` things that are happening although maybe those will +There's `clap` 3.0 things that are happening although maybe those will all be done by the end of the year. Who knows? But mostly, I want to address a pain point in application @@ -163,7 +169,7 @@ distributions, not just NixOS. Enter `cargo-dist`, a tool that can be used by a project to easily declare exportable artifacts and provides a way to tell an external -packaging tool (such as `nix`, or `dpkg`) where to copy files to make +packaging tool (such as nix, or dpkg) where to copy files to make a complete, working application. It steals borrows some concepts from autotools, using a `PREFIX` and several paths that artifacts can be copied into. This way a Rust application can easily -- cgit v1.2.3