Skip to content
This repository has been archived by the owner. It is now read-only.

/meeting-minutes

Permalink
Branch: master
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
85 lines (59 sloc) 5.55 KB
Raw Blame History

Attending

aturon, nmatsakis, brson, acrichto, pcwalton, huonw, wycats

Agenda

  • Subteam reports (subteam leaders)
  • RFC https://github.com/rust-lang/rfcs/pull/1156
  • Versioning/evolution strategy (nmatsakis, aturon)
  • Report from Rust class (nmatsakis)
  • 1.1, and release announcement plans (aturon/brson)

Subteam reports

https://github.com/rust-lang/subteams/blob/master/tools/reports/2015-06-16.md

https://github.com/rust-lang/subteams/blob/master/libs/reports/2015-06-16.md

https://github.com/rust-lang/subteams/blob/master/lang/reports/2015-06-16.md

Need to advertise these better to the community.

Default object lifetime bounds

https://github.com/rust-lang/rfcs/pull/1156

  • nmatsakis: I wound up implementing a system that gives you a warning basically if, and only if, your code would break under the change to defaults -- but doesn't actually make the change. I don't want to backport this to 1.1, because it hasn't been thoroughly tested and could ICE.

  • nmatsakis: Some people on thread have argued that having a period of warning prior to breakage would help when we need to make this sort of change.

  • wycats: Effectively deprecation?

  • nmatsakis: Yes.

  • nmatsakis: Effective policy: if we're making any kind of breaking change (soundness or not), the best option is deprecation + warning, next best is a legacy switch, and finally (only for soundness) we could pursue other options.

  • nmatsakis: Warnings can be hard, though, depending on the change.

  • wycats: [missed]

  • nmatsakis: I originally had this RFC modifying policy docs, but I've since pulled that out. I want to talk about interaciton with LTS. The change included reasoning about "recent stabilization", but better to work with LTS. [Some discussion around potential LTS cycles and how that interacts with course corrections.]

  • nmatsakis: So, maybe we should recap and see if we're all on the same page.

  • nmatsakis: Speaking specifically about course corrections:

    • They should be rare,
    • There should be a transition path,
    • They should not be visible to LTS users.

  • nmatsakis: For breaking changes with soundness implications, there aren't hard and fast rules, but best practice is:

    • There should be a transition plan
    • If possible, backport to previous LTS (particular if it can be construed as a security fix)

  • acrichto: IN the middle of an LTS release, we'd land the warning, and then make the breaking change?

  • wycats: The rule I'd like to follow is you should only give people deprecation-like warnings if there's something for them to work to -- you'd have to backport the fix.

  • nmatsakis: Usually in these cases, there is... though we'll probably have to see. In this particular example, there's a warning, and though I didn't backport a way to opt-in to the "fix", there's a simple workaround of writing the lifetime explicitly.

  • nmatsakis: You could also imagine backporting a legacy flag such that your code breaks but you can opt back out -- but less friendly than opting in, I think.

  • wycats: I think I'm more OK with flags if they don't cross LTS boundaries. IOW, people on LTS will never see them.

  • nmatsakis: I want to ask: is everyone in favor of this particular change?

    • Yes.

  • aturon: I'm worried about just landing this without explicit policy in place. What's the best way forward on continuing the policy discussion.

  • nmatsakis: option (1) a discuss post, option (2) an RFC

  • aturon: I don't think there's a huge difference between them, a discuss post gives more room for further input. Main thing is that we make clear (1) we're making a local decision about this RFC, (2) we have drafted a general policy that supports it which will undergo further discussion.

General consensus: let's make a discuss post on this topic.

Report from class using Rust

  • nmatsakis: Background: there was a course at Northeastern, with the topic being systems programming. It was taught in Rust. I got some reasonably detailed feedback from Matthias Felleisen and Jesse Tov. I plan to write a report, but want to share some of the highlights.
  • nmatsakis: Students found it rough in the beginning, but once they got the hang of ownership/lifetimes, it went fairly smoothly
  • nmatsakis: Nicest thing, when they moved into parallel programming, it was totally straightforward -- despite the students having no background in this.
  • nmatsakis: Students were given some tasks for concurrent programaming in Java, and people had a lot of difficulty. When they moved onto doing this in Rust, it Just Worked.
  • nmatsakis: They also did FFI work. They had a project where the job was to have C call into Rust, and then back. Most students did OK, but they had a lot of trouble getting the callback stuff working. Not too surprising since most of them hadn't done C before, so a lot of new stuff.
  • nmatsakis: Most suggestions were about error messages, and also requests for more explicit names for lifetimes (for teaching/learning purposes).
  • nmatsakis: For error messages, there were a lot of specific suggestions. For example, connecting error message phrases with parts of code they refer to using colors.
  • nmatsakis: They're going to teach this class again, and hope to develop it into a set of course materials that other universities can use.
  • aturon: Any complaints about compile times?
  • nmatsakis: No
  • acrichto: What about tool usage?
  • nmatsakis: They used Cargo, but not sure about much else.
  • acrichto: Calling into Rust from C is nontrivial.

1.1 release

Next Thursday! This is happening during the workweek. aturon to draft blog post, brson working on RELNOTES, will have everything in good shape by end of week.
You can’t perform that action at this time.