diff options
Diffstat (limited to 'content/blog/xxx_rust_2020.md')
| -rw-r--r-- | content/blog/xxx_rust_2020.md | 177 |
1 files changed, 0 insertions, 177 deletions
diff --git a/content/blog/xxx_rust_2020.md b/content/blog/xxx_rust_2020.md deleted file mode 100644 index 4339604..0000000 --- a/content/blog/xxx_rust_2020.md +++ /dev/null @@ -1,177 +0,0 @@ -Title: Rust 2020: the RFC process and distributions -Category: Blog -Date: 2019-11-11 11:11 -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. - |