Roadmap for 2019 #2657
Roadmap for 2019 #2657
Conversation
Centril
added
T-core
text/0000-roadmap-2019.md
Outdated
| They'll be working to fulfill these functions this year, along with looking | ||
| for ways to improve their internal processes. | ||
|
|
||
| Individual devtools subteams may be coming up with their own roadmaps, you |
There was a problem hiding this comment.
How many dev-tools subteams do we want to enumerate here? For example, i wrote out the roadmap for the Rustdoc Team over here, which was summarized in the All-Hands recap post for the dev-tools team.
There was a problem hiding this comment.
If you add it to the devtools repo I think we can list it here
There was a problem hiding this comment.
I'm not sure! It can't hurt to have it in the text, I think. I'm open to opinions!
There was a problem hiding this comment.
Yeah. We can inline the text or just put it in the devtools repo and link it, either works for me.
There was a problem hiding this comment.
I think putting it in the dev-tools repo and linking it here is probably best; since the IDEs roadmap is linked externally, adding a similar mention to rustdoc won't be too much of a stretch.
There was a problem hiding this comment.
Update: The Rustdoc 2019 roadmap is now live on the Dev-Tools Team repo. I don't know if you wanted to post an edit yourself, or if you wanted me to post a PR to add it to this.
There was a problem hiding this comment.
(The more the merrier, is my opinion)
There was a problem hiding this comment.
This still needs to be added btw
|
A quick note: the quote attributed to me isn't actually mine. Having said that, I do agree with the quote, but it's not from my post. :-) |
Sorry about that!
|
@cessen oops :( sorry about that! At least you know I did read your post, 🤣 😳 I've fixed it now. |
Thanks @distransient
|
There is one thing I was surprised to see not in the roadmap: discussion about the RFC/stabilization processes. Maybe it's just my perception, but it seems like a major theme that came up a few times and was raised by multiple leaders of the project (e.g https://internals.rust-lang.org/t/blog-rust-governance-scaling-empathy/9412, https://boats.gitlab.io/blog/post/rust-2019/). Is the plan to make a separate push independent of the roadmap? |
|
@mark-i-m this is a point @nikomatsakis and I went back and forth with; there's certainly general governance stuff that the core team wants to do this year. We were a bit unsure of the level of granularity we'd want to go into stuff like this, given that we don't know exactly how it will turn out, but maybe it's worth pointing out at a high level. Thanks for calling this out! |
|
Thanks @steveklabnik :) Yeah, I didn't necessarily mean a detailed plan, just a mention that this is something to be investigated this year. One other thing: are there any plans to do something like an |
|
I don't think that was explicitly discussed, but I think that after the big 2018 deadline, people aren't eager for more arbitrary deadlines this year :) at least, that's my rough take. Maybe it's a good idea! |
|
I guess an arbitrary deadline could be helpful for some periodic things like annual planning/roadmapping to help prevent the burden getting delayed or from falling on an individual (like you <3). But I was really thinking more of something like the impl Period: time specifically set aside for a purpose. I have read mixed feelings from different people about whether they thought the impl Period was productive or not, though... |
Hehe, yeah. That was just life this time though; I was advocating for this to be done by January, and then stuff happened. I think while the push for 2018 was going on, I didn't realize how tired I and everyone else would feel afterward.
So, the issue with the impl period (and I did hear this from a lot of people) was that it created pressure to ship RFCs before the cutoff. That's what I meant, more than the actual impl period itself. |
Co-Authored-By: steveklabnik <steve@steveklabnik.com>
|
@steveklabnik I got some feedback on the community team roadmap that I would like to include later today. |
text/0000-roadmap-2019.md
Outdated
| - Make plugins more discoverable. | ||
| - Provide library crates for parts of cargo to make it easier to create plugins. | ||
| - **Compile times:** | ||
| - Investigate ways that cargo can help to reduce compilation time, including potentially distributing binaries for builds from crates.io. |
There was a problem hiding this comment.
That would mean supporting binaries for a lot of targets (which is ok IMO). There can also be a target "MIR" where people could build crates from the MIR code, saving some time in parsing/type-checking/borrow-checking. This could be done with a fallback mechanism: is there a binary matching my target? if not use MIR, if that doesn't exist as well build from source.
There was a problem hiding this comment.
Of course there is the problem of conditional compilation (#[cfg(...)])...
There was a problem hiding this comment.
It also makes me a bit wary security-wise, but I guess that can be discussed at the time...
text/0000-roadmap-2019.md
Outdated
| itself, paying down technical debt in the codebase, and establishing themes | ||
| for long-term priorities. | ||
|
|
||
| ## Dev Tools |
There was a problem hiding this comment.
Getting cargo miri to stable would also be great.
There was a problem hiding this comment.
MIR isn't meant to be stable, so this can't really be done easily, nor do I think the MIR folks want to
(It's potentially useful to ship cargo miri with rustup on stable, though)
There was a problem hiding this comment.
(It's potentially useful to ship cargo miri with rustup on stable)
That's what I mean here. (But my other suggestion in the compile time section would imply a stable (or versioned) MIR.)
|
I'm skeptical of ever trying impl-periods again. In particular, I think @steveklabnik is right to say that it created pressure. I think the theme of this year, particularly wrt. "sustainability" suggests that we want to move away from such a development model in which we cram development into one period and proposals into another. Instead, we should have a more balanced, organic, and less forced way of doing things. Also, the impl-period idea might fit our rather serial model today but I think it fits poorly with a the parallel nature of the working group model where they spin up and down and they work at different paces. It also seems to me that impl-periods foster unhealthy and periodical workloads for the language teams and compiler teams respectively. |
|
My sense is that we are not planning an "impl Period"-like push this year. With respect to text about revamping the RFC process or other such governance changes, I think it's probably a good idea, but couldn't quite figure out where it should fit when I was making changes. Part of the problem is that I don't really view this as such a "top-down effort" any more. I think what we want is individual teams working on their process, and some kind of working group ("governance working group") that is helping to carry lessons between teams and to brainstorm with teams about possible improvements to address their problems. The point here being that a lot of this work is falling on teams, and I do think that many of the individual teams noted their desire to make organizational changes, so in some sense the work is already represented. That said, it seems like it would add clarify overall to identify that we intend to be actively working on our governance this year across the project. Perhaps @steveklabnik we should add back the Core Team section you originally had, with some text like this? Core team A major focus for the core team this year will be reviewing and revising our governance process to better fit our current needs. A number of the teams are already actively changing their structure to better cope with organizational debt, and the core team intends to help with that process where possible. Some possible changes include creating new mechanisms for better inter-team communication, improvements to the RFC process, and creating new teams for areas where we don't currently have coverage. |
|
I like it! I still plan on filing an RFC for a staged RFC process, personally. I think it'll be really great for us. |
text/0000-roadmap-2019.md
Outdated
| The team doesn't currently have the bandwidth to take on a large number of | ||
| new features for the standard library, but is specifically planning to | ||
| develop a plan of attack for custom allocators associated with instances of | ||
| collections (e.g. `Vec<T, A: Alloc>`). |
There was a problem hiding this comment.
cc @rust-lang/release Do we want to say anything here?
(also @rust-lang/infra is missing but y'all presumably have plans re. CI?)
There was a problem hiding this comment.
Both teams opted to not add anything specific.
There was a problem hiding this comment.
@steveklabnik Well... at least for T-Release iirc we didn't really discuss the RFC itself... more like the roadmap in general; but we probably should do that next Wednesday. :)
There was a problem hiding this comment.
I checked with @Mark-Simulacrum and @aidanhs and they both felt like they didn't want to add anything, but I'm certainly game to include plans that exist. =)
|
This looks great overall! :D I am a little puzzled to see the "Async Ecosystem" section mention Tide but not Tokio though? Shouldn't moving Tokio onto |
|
Are there any plans to tackle the remaining proc macros features this year? These (along with the never type, but that could probably be worked around) are the remaining issues blocking Rocket from working on stable. Which, with Rocket planning to go async in their next release, would be fantastic from an Async Ecosystem perspective. Compile with stable Rust: rwf2/Rocket#19 |
text/0000-roadmap-2019.md
Outdated
| > at every level of our organization that need to be addressed, and I’m going | ||
| > to enumerate them from my personal perspective. | ||
| > | ||
| > - withoutboats, ["Organizational Debt"](https://boats.gitlab.io/blog/post/rust-2019/) |
There was a problem hiding this comment.
So while this was one of the posts that I saw a number of people quote and at least for me generated a lot of recognition, it feels like the RFC covers very few of the issues, or in general, the topic of organizational debt. Adding back the core team section to suggest work on governance might help with that a little bit, but feels to me like it doesn't give this group of issues the priority that it deserves.
From what I've seen in "All Hands" notes - not as a part of the official roadmap. |
This is not how our roadmap process really works, that is, we don't have this as a current requirement of the process. Describing details around how a group's goals apply to their projects is pretty normal. For example:
The Async Ecosystem WG mentioning tide fits right in with these kinds of things. This comes out of RFC 1728, which lists both "problem statements" as well as "goals". And it does say that the roadmap should be the problem statements, and then that for each release cycle, the teams would plan out specific goals that refered to a problem statement. In practice though, things didn't play out that way. In our 2018 roadmap, both problems and goals are identified throughout. The guide-level explanation lays out the problems, and then the detailed explanation lays out the goals. Personally, I believe this happened because an open source project like Rust doesn't work the same way as a company does; trying to model agile too directly doesn't really work in this environment. But I digress. Ultimately, this year's RFC follows in the footsteps of last year's. And regardless, litigating the form of roadmaps generally is not really on-topic for this particular roadmap. If you'd like to see the Async Ecosystem WG drop Tide as a project, I'd suggest reaching out to the leads as I mentioned before, or attending the WG's open meetings on Thursdays. |
|
That's a good point. I guess the core of my gripe is around the perceived focus of Tide vs the ecosystem writ-large given the name of the team. I feel like the primary focus should be "help expand the ecosystem around async/await" (the second part listed in the RFC), with Tide being a particular way the WG intends to do that. While I personally don't see how focusing on Tide contributes to the ecosystem, I agree with you that the Roadmap mentioning Tide isn't uncharacteristic of past Rust Roadmaps. I'll try to find a way to reach out to the Async Ecosystem WG to discuss directly there. |
Here is their Discord channel: https://discordapp.com/channels/442252698964721669/474974025454452766 They have a weekly meeting on Thursdays via that channel, so they may take up your concerns as an item to discuss if you can write them up tonight. (I'm not a member of that WG, though, so I can't speak for them or promise that they'll modify their agenda on your behalf.) |
I suppose if you put it like that, the majority of the issues that boats mentioned are covered somewhat. I feel the money issue is not covered in the roadmap at all, and is something that is top of mind for me; not just the issue of how we can compensate productive contributors, but also how we grow the financial resources that the Rust project can leverage. As far as I understand, two people have left Mozilla Corporation's Rust team with no sign of replacement happening -- does that represent a position that MoCo will scale back their direct contribution definitively? On the overall RFC, for me it ends up feeling not very coherent and rather fragmented -- this is probably a result of the choice to present everything by team. I feel the RFC would probably read stronger for outside users like myself if it was presented more as (a) problem identified by survey or blog post, (b) proposed solution with (c) SMART goals possibly subdivided by teams. I also feel even with the added section on the core team, the governance theme isn't very well represented. |
text/0000-roadmap-2019.md
Outdated
| - finding out what needs are yet to be addressed by tooling and filling them | ||
| - providing some kind of quorum helping smaller tool subteams make decisions | ||
|
|
||
| They'll be working to fulfill these functions this year, along with looking |
There was a problem hiding this comment.
For a roadmap, the approach of listing "core functions" and then saying the team will work to fulfill these functions this year seems a bit weak. Is that different from last year, and if so, how? If all the specific measurable goals are pursued by subteams, maybe this section can just be left out?
There was a problem hiding this comment.
It is different from last year, last year the devtools team didn't really have these core functions. It somewhat implicitly did but didn't necessarily actively pursue them. We've only recently enumerated these and decided to start moving towards them.
I don't consider the roadmap to be a place for only measurable goals.
text/0000-roadmap-2019.md
Outdated
|
|
||
| ## Documentation | ||
|
|
||
| The documentation team is going to be completely reformulating itself, and |
There was a problem hiding this comment.
Is the idea that the learning team RFC will still be in time for this RFC?
This is good feedback, thanks. I too am unsure what I think about the team-based format for the roadmap. In fact, @steveklabnik and I already privately expressed some similar reservations of the format, but we ultimately opted not to try and reorganize everything. Part of the reason for this is time: we are already running later than we'd like to get this RFC posted, and I'd rather not introduce further delay. I definitely think that, when it comes time for next year's roadmap, we should revisit some of these ideas. That said, once the RFC is merged, we have traditionally made a blog post, which is usually the main "point of entry" for people to read about the roadmap. Our plan was to try and give a more "integrated" presentation there.
My expectation is that the governance WG (just announced!) -- or a successor, depending on how we scope things -- will tackle some of these topics, but not initially. I think it makes sense to let us figure out the processes that work best for these sorts of discussions first.
As the current manager of Mozilla's group, I can speak to that. There has been no change in Mozilla's commitment to Rust. We are working on getting authorization to hire replacements for those who left, but that process takes time. |
|
@rfcbot fcp merge I think it's time to merge this roadmap, and get started on making it a reality! Thanks to everyone for the discussion and feedback. |
|
Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged team members:
No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
rfcbot
added
proposed-final-comment-period
Add link to rustdoc roadmap
rfcbot
added
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
|
By the way, it appears that the rfcbot has not been updated to account for some core team changes. I've checked a few names off on the comment above, and I'm going to manually add one here that is missing: |
|
@nikomatsakis Please send a PR against https://github.com/anp/rfcbot-rs/blob/master/rfcbot.toml updating the roster of the core team. :) |
|
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon. |
rfcbot
added
finished-final-comment-period
|
🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 As usual, we will be putting out a blog post on the blog, summarizing the roadmap for the community. Expect that early next week. |
|
Rendered version link is broken. |
|
It's merged here: https://github.com/rust-lang/rfcs/blob/master/text/2657-roadmap-2019.md |
|
Updated. |
This RFC proposes the 2019 Rust Roadmap, in accordance with RFC 1728. The
goal of the roadmap is to lay out a vision for where the Rust project should
be in a year's time.
You can view the rendered version here.
The proposal is based on the 2018 survey, our annual call for blog posts,
direct conversations with individual Rust users, and discussions at the 2019
Rust All Hands. Thanks to everyone who helped with this effort!
In short, 2019 will be a year of rejuvenation and maturation for the Rust
project. Much of the focus is on strengthening our foundations and
paying down debt, both technical and organizational.
Thanks to everyone for being patient while we got the roadmap together; it took a bit longer than we'd like, but I'm very pleased with the result! Furthermore, while I am the one opening this RFC, I'd like to thank @nikomatsakis for putting in a lot of work and revisions, and the teams generally, who put together their plans and gave feedback.