Preparing Rust 2020 roadmap article for publishing

1 files changed, 177 insertions, 0 deletions

diff --git a/content/blog/111_rust_2020.md b/content/blog/111_rust_2020.md
new file mode 100644
index 0000000..0d27df9
--- /dev/null
+++ b/content/blog/111_rust_2020.md
@@ -0,0 +1,177 @@
+Title: Rust 2020: the RFC process and distributions
+Category: Blog
+Date: 2019-11-04 10:00
+Tags: /dev/diary, rust, roadmap
+
+I must have missed an e-mail in my inbox, because recently I started
+seeing people publish Rust 2020 blogposts so I thought, why not. I
+haven't been incredibly involved in the development of Rust in the
+last few months, (navigating the delicate balance of being self
+employed, working on free software and not burning out) but I feel
+like that might change again. And also, I still have *feelings about
+software*.
+
+This post was also largely inspired by my friend [XAMPPRocky's post][erin],
+as well as attending [NixCon][nixcon] a few weeks ago, and generally
+interacting with the NixOS RFC process.
+
+[erin]: https://xampprocky.github.io/public/blog/rust-2021/
+[nixcon]: https://2019.nixcon.org/
+
+## What even is an RFC?
+
+An RFC, or "request for comments" is a mechanism by which a group of
+people can get feedback from a wider community on proposed
+changes. The idea being, that a proposal is written, outlining it's
+scope, implementation details, retionale and impact on the ecosystem,
+then people make comments on the proposal. Usually by the time that
+everybody has stopped shouting at each other, the RFC is ready to be
+merged, meaning it is accepted and it's vision can be
+implemented. This can either be implementing a feature, or removing
+`unstable` flags from it.
+
+Unfortunately I'm not being too flippant here: the procedure of how an
+RFC goes from "proposed" to "accepted" is very vague and can depend on
+*a lot* of factors. Needless to say, this can also be the source of a
+lot of conflict in a community.
+
+Rust has had an RFC process for a few years now, and most, if not all
+decisions to the language and ecosystem have gone through it, and the
+community feedback it entailed. Some go largely overlooked, like [this
+one][rfc1] that I co-authored at the Rust All Hands 2018 in Berlin
+(it's fine, I understand), others get hundreds of comments. This often
+results in no meaningful conversations, in large parts because it's
+hard to have a discussion with 1000 people, and in other part because
+GitHub is a *terrible* platform to do anything on (sequel hook).
+
+[rfc1]: https://github.com/rust-lang/rfcs/pull/2376
+
+## RFC chaos
+
+I remember this issue first coming up in the module refactoring
+debates and the three (?) RFCs that were in total created before
+everybody felt happy enough about it. These were the first large RFCs
+I witnessed while being kinda part of the community. Many of the
+people who were involved in them talked about how stressful it had
+been and I think they might also be the first time that the RFC
+process, the way that the Rust project implemented it, started showing
+limitations of scale.
+
+The fact that an RFC is proposed, with no real structure or framework
+on how to continue afterwards means that either feedback is chaotic
+and iterations on the design can seem arbitrary, and on the other hand
+some RFCs remain open for years, in limbo, where nothing really
+happens on them. Both aren't great outcomes, add to stress for the
+people who were involved in writing them, and generally just slows
+down our decision making process.
+
+As XAMPPRocky wrote in her blog post:
+
+> When 1.0 launched there was ~30 members of The Rust Programming
+> Language, now in 2019 we have ~200 members. This is nearly 7x the
+> amount of members, yet we've changed very little to be able to adapt
+> to this growth.
+
+While she was talking about how many people get paid for Rust, I feel
+this is also applicable to the way that we make decisions. I wrote
+about this as well in my [Rust 2019][rust2019] post, without giving
+specific examples on how to fix it. Well, I'm mentioning it again,
+because I feel like we should try something concrete.
+
+[rust2019]: https://spacekookie.de/blog/rust-2019-how-we-make-decisions/
+
+## Shepherds and an RFC committee
+
+The NixOS project has two concepts in their RFC process which I think
+are valuable and that the Rust project would benefit from: RFC
+Shepherds and the RFC steering committee.
+
+The RFC steering committee is a group of between 5-6 people, assigned
+for a year to oversee any new RFC, make sure that shepherds get
+assigned to it, and also keep tabs on progress that is being made. Are
+shepherds regularly (in whatever interval they deem appropriate)
+meeting to discuss the RFC, is feedback being taken into account by
+the authors, how the discussion generally going?
+
+They *do not* need to actually understand where the discussion had
+headed, but make sure that a discussion is happening. This would solve
+the problem of RFCs remaining open for years, without getting any
+further feedback and cluttering the PRs page of open RFCs. RFCs that
+were forgotten about by their authors or that the community has
+largely moved on from can be closed/ rejected. It can also give
+closure to people who have written RFCs that was never rejected, but
+not accepted either (again, I'm cool, don't worry).
+
+RFC shepherds are then assigned to an RFC (3-5 people) to actually
+oversee the discussion and consolidate feedback into changes that can
+be made on the RFC. They are also responsible for regular (again, up
+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.
+
+## 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.
+
+I haven't followed a lot of progress from the governance workinggroup,
+but reading their charter and some of the proposed [RFC stages][gov]
+might address some of the issues in the process. I feel that
+introducing a new RFC governance body (a set of people who rotate) as
+well as the concept of RFC shepherds would be beneficial to the Rust
+project as a whole, and anyone who's involved in any RFC related
+discussions in the future.
+
+[gov]: http://smallcultfollowing.com/babysteps/blog/2018/06/20/proposal-for-a-staged-rfc-process/
+
+There's some tooling issues to address as well, but I feel those are
+second to the social ones.
+
+## Distributing Rust code
+
+Wow, yea this was supposed to be a post about Rust 2020 and my
+personal roadmap. While I would love to be involved co-authoring an
+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
+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
+improvements to the crate itself, as well as compatibility with other
+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
+all be done by the time of the near year. Who knows?
+
+But mostly, I want to address a pain point in application
+packaging. Over the last year I've been tricked into maintaining a
+Linux distribution, NixOS. And while I'm not _that_ involved in the
+development of it, there's some things that often come up with
+packaging Rust applications that could and should be better.
+
+Mostly this is about applications, written in Rust, that want to
+distribute artifacts other than their binaries as well. Be that
+generated man pages, default configuration, or static files for a
+website. Currently this process is entirely up to the packager of an
+application and relies heavily on the application in question having
+good documentation. This is also a problem for _all_ Linux
+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
+a complete, working application. It <del>steals</del> borrows some
+concepts from autotools, using a `PREFIX` and several paths that
+artifacts can be copied into. This way a Rust application can easily
+be made into a package by calling `cargo dist`, which internally does
+a release build, and exports required artifacts to the appropriate
+places.
+
+All of this is pretty WIP and local on my laptop right now. But I
+would love to finish it soon, and see projects in 2020 adopt this as a
+standard to distribute files for Rust packaging.
+