1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
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.
|
