Announcing the "impl period", Sep 18 - Dec 17!

announcements
1

July is ending, meaning there are only five more months left in the year!

I’ve been talking with the core and subteams about how we’d like the rest of the year to look. We’re in a decent position, but we’re going to need a lot of focus to fully bring the roadmap to fruition this year. We need to be essentially done by the end of November, leaving December for focusing on the retrospective and next year’s roadmap (and holidays etc).

Here’s what we’re planning–and I hope that this will become part of our annual roadmap cycle:

  • The three month period from Sept 18 to December 17 is considered the “impl period” for the year.
  • As a community, we come together during this period to focus on “implementation” work, as opposed to design/RFC work.
    • The primary focus will be implementing accepted RFCs (or other established visions, e.g. the Libz Blitz) that are important for this year’s roadmap.
    • “Implementation” covers all work that can result in a PR to a shipping artifact, including documentation, error messages, library API PRs, compiler work, etc.
  • Ahead of the impl period, the subteams will prepare Request for Implementation (RFIs), outlining work that is planned, who plans to lead each effort, and opportunities to get involved. These will be posted on the internals forum and kept up to date wiki-style (similarly to the Libz Blitz tracker).
    • This is a great opportunity to get mentored, to coordinate closely with subteam members on high impact work.
  • During this time, the subteams will not plan to merge any RFCs, except if absolutely needed for implementation.
  • We will also try to host related hack sessions before or after Rust Belt Rust and RustFest Zurich; more on that soon!

This plan effectively sets a deadline for design work that will contribute to this year’s roadmap, and gives us a chance to “switch gears” a bit and all push on executing the plan we’ve decided on. The core team is really excited about this chance to work together!

Here’s a rough anticipated schedule:

  • August

    • Remaining planned RFCs posted:
      • NLL, module system, lifetime elision improvements, coercions, string literals, …
      • Cargo build system integration vision
      • Your RFC here!
    • Switch to new incremental compilation approach
    • MIR borrowck lands (via flag)
    • New rustdoc under very active development
    • Rust Reach kicks off
    • Generators land in nightly
      • Together with error message infrastructure that’s already landed, gives us a solid async/await experience on nightly
    • http 0.1 published

  • September

    • RLS beta starts riding the trains
    • Libz Blitz official evaluations complete
    • Decisions (including potential postponement) reached for all major roadmap RFCs
    • 18th, the impl period kicks off

  • During impl period

    • Accepted lang and Cargo RFCs implemented (major source of work)
    • MIR borrowck fully working, plus other NLL support (assuming RFC lands)
    • Tokio/Futures improvements, including completely new docs (Edit: removed reference to 0.2)
    • Libraries taking part in the Blitz reach 1.0
    • Ship 1.0 synchronous http server and client libraries, built on http and hyper
    • Ship first edition of Rust Cookbook
    • Ship first edition of Rust API Guidelines
    • Revamp Cargo docs
    • Revamp web sites (main site, crates.io)
    • New rustdoc at parity with existing rustdoc, and starting to explore new design space
    • Some pieces of the Chalk-inspired revamp of the trait system
    • The new Rust book is finalized and ready for print
    • Undoubtedly more! I haven’t yet fully canvassed the subteams for their plans – this is just a sketch

  • December

    • Produce retrospective and blog post for the year
    • RFC for next year’s roadmap

There are a couple of stretch goals for the impl period:

  • Complete Chalk-inspired revamp of the trait system
    • Should improve compiler performance, but also unlocks generic associated types (aka ATCs) and more.
  • const generics

Most likely, neither of these will make it this year, but would be expected early next year.

As I said above, prior to the impl period actually starting, the subteams will produce a more detailed plan together with clear opportunities for mentoring and contribution.

Let me know what you think!

63 Likes
2

Where is the info on the tokio/futures 0.2 revamp?

5 Likes
3

This looks like a great idea to me. I’ve been feeling for a while that the work done by the teams has felt a bit too fragmented for my taste, and focused too much on many different design issues versus doubling down more on execution and implementation of the most important issues (NLL is top of my mind for me).

Longer term, do you feel that the distribution of 75% focus more on design, 25% focus more on implementation is the right balance? I could for example imagine wanting a bit more balance, like interleaving design-focused quarters with impl-focused quarters. (In that case, maybe the rules should be more nuanced, like smaller RFCs could still be merged.)

In terms of evaluating the roadmap position, do you feel that the roadmap tracker repository has satisfied the goals/plan for it as set in the beginning of the year? If I look at the libs/lang roadmap issues right now, they don’t necessarily look all that well-aligned to the projects you’ve mentioned here.

4

Will this be exclusively for 2017 roadmap items? Any chance of seeing forward progress on the never type and/or the TryFrom trait?

Something I hope to see discussed in December for next year is how to better pace both planning and implementation over 2018. I think it’d be great if there was a more steady pace of things being stabilized over the year, rather than the heavy planning and last minute rush to implement and stabilize that we’re seeing this year.

3 Likes
5

A three-months period planned a month and a half in advance is arguably not a “last-minute rush”.

6 Likes
6

I don’t think its a rush, but I do think our process this year has been a bit ‘waterfall’ and there are probably learnings to improve it next year. I’d like to see more eRFCs, for example.

3 Likes
7

Nothing much has been written up yet, but what I'm hoping to see includes:

  • Drastically simplifying the story around Core/Handle/Remote, potentially providing global event loops and the like.
  • Focusing Tokio more purely on "mid-level" async IO, rather than the current focus on tokio-proto; essentially, breaking up the stack a bit to have greater focus for each piece.
  • A complete revamp of the documentation, in line with the above, and also providing reams of examples.
    • As part of this, I'd like to see some documentation introducing futures via async/await syntax to start.

I'm not sure how all of this is going to turn out, but these are at least the high level concerns I have in mind. More details around the impl period!

I think that's not the right way to understand what's happening; there's been quite substantial focus on implementation work throughout the year (e.g. on incremental compilation, NLL, library work, etc). To me, it's more a matter of having a clear cutoff point for major RFCs that will "make it" for the year, and providing an opportunity for us as a community to change gears for a bit.

By contrast, closing down the RFC process for more than a quarter of the year feels a bit too strong to me.

But in any case, we'll know more by the end of the year, and can take that into account when planning next year!

So the team roadmap issues have not been kept up to date. By contrast, the project roadmap issues (e.g. ergonomics) has been.

On the whole, I'd say that the tracking repository has been a mixed experience, and we may want to try a different approach next year.

Roadmap items are prioritized, but we continually accept other RFCs and stabilizations. I think TryFrom is plausible, but the never type is less likely this year (because it hit on substantial thorny implementation issues, and does not merit the time needed at this point).

Hm, so to clarify, the impl period is about implementation, and very much not stabilization! As I said above, it's a misunderstanding to think we've waited until this point to do any implementation work; it's been happening continuously. This is more about recognizing a point in the year where further design work on the roadmap is no longer feasible, and we should focus wholly on completing implementation work that was already ongoing.

With respect to the timeline: certainly going forward I would expect to have more of the "seasons" of the year set in advance. The idea of the impl period was something that occurred to us relatively recently, hence the somewhat late announcement. As with all Rust processes, expect iteration and experimentation!

Yes, in general the RFC process is currently calibrated too far on the waterfall side. That's one among many improvements that'd be good to make around RFCs going into next year.

5 Likes
8

That seems contrary to the point of rapid calendar-based releases: no rush up to a deadline to “make it” by, the next release train is always less than 6 weeks away. But we’ll see how it goes.

4 Likes
9

What are eRFCs?

10

“Experimental RFCs”. I believe https://github.com/rust-lang/rfcs/pull/2033 is the only eRFC that’s been proposed/accepted thus far.

1 Like
11

Hm, I understand this kneejerk reaction but have a different perspective:

  1. The release process, which depends on stabilizations, continues exactly as it has been; the impl period is emphatically not about rushing stabilizations.
  2. The "cutoff point" is mostly about acknowleding reality: if a major RFC hasn't been merged by mid-September, it's just not realistic to complete the design and implement it in the remainder of the year.
  3. More to the point, part of what we're trying to achieve here is having a bit more of a varied rhythm/seasonality to the year. Right now we mix design/RFC and implementation work in a continuous fashion, which can make it feel like the work is endless. Having some more clear-cut periods with concrete goals and greater focus will, I think, be a breath of fresh air and quite energizing for the whole community.

That said, it's absolutely true that this timeline exerts some pressure on the RFC process -- partly by design. Quality concerns are mitigated by the fact that consensus is still needed, and that stabilizations occur separately.

7 Likes
12

Oh. I was wondering what the whole point of the arbitrary deadlines (end of year?) was, I guess that explains it. Doesn't particularly interest me, but if it rocks your boat.

However, RFCs definitely deserve plenty of time for development, review and comment. From that perspective, there shouldn't really be any reason they can't be delayed a short while if necessary, or a real need to shoot for a deadline.

13

There are two features mentioned on the roadmap which I think would be very nice ergonomics improvements, but don’t have an RFC yet.

  • AsRef coercions
  • Auto-Deref copy types

Are those what is metntioned as “coercions” in @aturon s post?

Also, what is “string literals” (also under planned RFCs) referring to?

14

I think there are also the RFCs on macros 2.0 which were basically eRFCs without the label (because the RFC that defined experimental RFCs didn’t exist back when they were created).

15

This all ties back to the roadmap process, which is set on a yearly cycle. In order to ship, we need to be clear about the direction we want to go on, lay out a realistic set of goals for a time period, and focus.

The yearly cycle is no more arbitrary than our six week release cycle is. Both time frames were chosen carefully, taking into account a number of important social and managerial considerations.

Of course. Most of the major RFCs for the roadmap have been in development for months at this point. But again, the point here is to switch gears for a few months and focus on implementing what we've already approved toward the roadmap, to ensure we actually ship in a timely fashion.

Yes. After exploration, though, it's not entirely clear that this approach will solve the bulk of the problem around Copy types. @cramertj is currently thinking through some alternatives that focus more on our operator traits specifically (which is where the problems most commonly occur).

It refers to ideas presented in this thread. However, it seems that the "copy-on-write" strategy is essentially unworkable (for some technical reasons I don't have time to detail right now), and that in general the issues with strings span a number of different areas. Unfortunately, I think it's unlikely that we'll have a design ready for this year's cycle.

16
  • Ahead of the impl period, the subteams will prepare Request for Implementation (RFIs), outlining work that is planned, who plans to lead each effort, and opportunities to get involved. These will be posted on the internals forum and kept up to date wiki-style (similarly to the Libz Blitz tracker).
    • This is a great opportunity to get mentored, to coordinate closely with subteam members on high impact work.

I'm especially excited for this part. I would love to get an opportunity to work on the compiler. To be honest I've been a bit too intimidated until now. :sweat_smile:

As I said above, prior to the impl period actually starting, the subteams will produce a more detailed plan together with clear opportunities for mentoring and contribution.

Is there a way to get started on this already, or do I need to wait until Sept 18 to find out more? How can I keep up and make sure I don't miss anything?

17

I wonder if it might make sense to have a softer cutoff, such as:

  • Only those RFCs will be implemented during the impl period which were merged before it began
  • Only those RFCs will potentially be considered to be merged during the impl period which were submitted before it began

So it’s a bit more of an epoch-ish sliding window. Basically the concrete difference relative to the current plan is that if an RFC was already submitted before the impl period began, we wouldn’t promise not to merge it. (We would promise not to begin implementation of it.) This doesn’t change the fact that the focus would first and foremost be on implementation work; just gives long-languishing RFCs the chance to move forward, at the team’s discretion, provided that it doesn’t require diverting much effort/energy. The RFC process would merely be put into the refrigerator, rather than the freezer.

1 Like
18

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.