Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roadmap for 2019 #2657

Merged
merged 10 commits into from
Mar 30, 2019
Merged

Roadmap for 2019 #2657

merged 10 commits into from
Mar 30, 2019

Conversation

steveklabnik
Copy link
Member

@steveklabnik steveklabnik commented Mar 7, 2019

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.

@Centril Centril added T-core Relevant to the core team, which will review and decide on the RFC. A-roadmap Proposals for Rust project roadmaps . labels Mar 7, 2019
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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you add it to the devtools repo I think we can list it here

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure! It can't hurt to have it in the text, I think. I'm open to opinions!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. We can inline the text or just put it in the devtools repo and link it, either works for me.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(The more the merrier, is my opinion)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This still needs to be added btw

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cessen
Copy link

cessen commented Mar 7, 2019

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. :-)

@steveklabnik
Copy link
Member Author

@cessen oops :( sorry about that! At least you know I did read your post, 🤣 😳 I've fixed it now.

@mark-i-m
Copy link
Member

mark-i-m commented Mar 7, 2019

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?

@steveklabnik
Copy link
Member Author

@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!

@mark-i-m
Copy link
Member

mark-i-m commented Mar 7, 2019

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 impl Period? Past roadmaps have included timelines for key events (e.g. 2017 impl Period or 2018 edition).

@steveklabnik
Copy link
Member Author

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!

@mark-i-m
Copy link
Member

mark-i-m commented Mar 7, 2019

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...

@steveklabnik
Copy link
Member Author

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).

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.

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...

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.

text/0000-roadmap-2019.md Outdated Show resolved Hide resolved
Co-Authored-By: steveklabnik <steve@steveklabnik.com>
@skade
Copy link
Contributor

skade commented Mar 8, 2019

@steveklabnik I got some feedback on the community team roadmap that I would like to include later today.

- 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.
Copy link
Member

@orium orium Mar 8, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

@orium orium Mar 8, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of course there is the problem of conditional compilation (#[cfg(...)])...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It also makes me a bit wary security-wise, but I guess that can be discussed at the time...

itself, paying down technical debt in the codebase, and establishing themes
for long-term priorities.

## Dev Tools
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Getting cargo miri to stable would also be great.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(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.)

@Centril
Copy link
Contributor

Centril commented Mar 8, 2019

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.

@nikomatsakis
Copy link
Contributor

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.

@steveklabnik
Copy link
Member Author

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.

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>`).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both teams opted to not add anything specific.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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. :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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. =)

text/0000-roadmap-2019.md Outdated Show resolved Hide resolved
@jonhoo
Copy link
Contributor

jonhoo commented Mar 8, 2019

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 std futures be a major push, since there's so much ecosystem around that already? Whereas, as far as I can tell, Tide isn't really being used yet.

@nicoburns
Copy link

nicoburns commented Mar 8, 2019

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

> 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/)
Copy link
Contributor

@djc djc Mar 8, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@petrochenkov
Copy link
Contributor

@nicoburns

Are there any plans to tackle the remaining proc macros features this year?

From what I've seen in "All Hands" notes - not as a part of the official roadmap.
I'm going to work on feature(proc_macro_hygiene) occasionally, so parts of it could be stabilized.

@steveklabnik
Copy link
Member Author

I would much rather have the Roadmap list the overarching goal and motivation of each WG than specify internal details;

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 cargo team lists "Xargo, cross, Rustup, and WASM-Pack"
  • The compiler team talks about RLS 2.0
  • The CLI WG talks about assert_cli, assert_fs, and assert_cmd
  • The Wasm WG talks about wasm-pack

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.

@jonhoo
Copy link
Contributor

jonhoo commented Mar 13, 2019

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.

@BatmanAoD
Copy link
Member

@jonhoo

I'll try to find a way to reach out to the Async Ecosystem WG...

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.)

@djc
Copy link
Contributor

djc commented Mar 18, 2019

@nikomatsakis

I feel overall pretty comfortable with this. I'd be interested to know if there are specific organizational challenges that you think are not represented in the quotes above.

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.

- 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


## Documentation

The documentation team is going to be completely reformulating itself, and
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the idea that the learning team RFC will still be in time for this RFC?

@nikomatsakis
Copy link
Contributor

@djc

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.

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.

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.

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.

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?

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.

@nikomatsakis
Copy link
Contributor

@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.

@rfcbot
Copy link
Collaborator

rfcbot commented Mar 19, 2019

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 rfcbot added proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. disposition-merge This RFC is in PFCP or FCP with a disposition to merge it. labels Mar 19, 2019
@rfcbot rfcbot added final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. and removed proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. labels Mar 20, 2019
@rfcbot
Copy link
Collaborator

rfcbot commented Mar 20, 2019

🔔 This is now entering its final comment period, as per the review above. 🔔

@nikomatsakis
Copy link
Contributor

nikomatsakis commented Mar 20, 2019

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:

@Centril
Copy link
Contributor

Centril commented Mar 20, 2019

@nikomatsakis Please send a PR against https://github.com/anp/rfcbot-rs/blob/master/rfcbot.toml updating the roster of the core team. :)

@rfcbot
Copy link
Collaborator

rfcbot commented Mar 30, 2019

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 rfcbot added finished-final-comment-period The final comment period is finished for this RFC. and removed final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. labels Mar 30, 2019
@steveklabnik steveklabnik merged commit df984ba into rust-lang:master Mar 30, 2019
@steveklabnik
Copy link
Member Author

🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊
The 2019 Roadmap has been merged!
🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊 🎊

As usual, we will be putting out a blog post on the blog, summarizing the roadmap for the community. Expect that early next week.

@steveklabnik steveklabnik deleted the 2019-roadmap branch March 30, 2019 14:30
@andradei
Copy link

andradei commented Apr 2, 2019

Rendered version link is broken.

@tesuji
Copy link
Contributor

tesuji commented Apr 2, 2019

@Manishearth
Copy link
Member

Updated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-roadmap Proposals for Rust project roadmaps . disposition-merge This RFC is in PFCP or FCP with a disposition to merge it. finished-final-comment-period The final comment period is finished for this RFC. T-core Relevant to the core team, which will review and decide on the RFC.
Projects
None yet
Development

Successfully merging this pull request may close these issues.