- pcwalton, wycats, nmatsakis, huon, acrichto, aturon, steveklabnik
- rustcamp status (nmatsakis, aturon)
- Community subteam (aturon)
- Book reviewing (aturon)
- sem versioning and major versions (nmatsakis) (also might discuss API semver)
- Need people to provide technical reviewing for upcoming external book on Rust.
- Made an announcement of date (http://rustcamp.com/)
- CFP June 1st - 21st
- CFP App setup by Steve
-
Focus should be:
Playing a leadership role in inclusiveness/diversity for Rust. That might include developing project policies, helping kick off outreach efforts, and raising awareness of problems, among other things.
Coordinating and collecting useful information for local events. That might include accumulated wisdom, a joint calendar (which we already have), maintaining information about local efforts happening around the world, and so on.
Creating and maintaining re-usable community materials. That might include slides, videos, and other artifacts from tutorials, meetups.
Outreach. That might include talking to organizations devoted to underrepresented groups, as well as finding venues not traditionally oriented toward systems programming.
Coordination with production and commercial users of Rust. This might include setting up regular meetings/town halls or other ways for production users to talk to each other, and to get the ear of the core team for setting priorities etc.
-
There hasn't been a great deal of feedback, but we want to keep momentum going on this so we are moving forward with creation of the team.
- Niko wrote an RFC about semantic versioning for the language. Seems like there are two philosophies about how we're going to grow Rust.
- This RFC seems to interact with the schedule for major versions.
- The RFC focuses on changes allowed in minor releases. The angle was to allow maximal flexibility in a minor release.
- But maybe another strategy is to say that we expect major versions more frequently, and when we want to add major new/back-incompat features, start thinking about a new major release.
- Then features would be e.g. a 2.X feature that you can get early access to (opt in) within 1.X.
- Could do without opt-in versioning, perhaps, in this model.
- wycats: If we want e.g. annual major releases, very important for them to be painless.
- nmatsakis: Yes, and slow/painful major releases haven't worked out well in practice for other languages.
- nmatsakis: There may be a few "course corrections" -- small tweaks that are not backcompat, but have low impact (as measured by crater). For example, I think the defaults on object lifetimes are slightly suboptimal.
- nmatsakis: Maybe we don't get to make that change, or maybe we permit it as an "early", "minor" tweak after a major release.
- wycats: I think in today's situation, where there just aren't that many crates, you can just reach out to people/fix it.
- nmatsakis: But in the future -- say, after 2.0 -- what can we do then?
- aturon: In the future, we'll have more time to test out features as unstable, so hopefully the need for this kind of tweaking will decrease.
- nmatsakis: Yes, so maybe we should give a policy that rules this kind of tweaking out, and then just write some early post-1.0 RFCs that are judged as exceptions to the policy.
- wycats: People underestimate the impact of stackover answers, blog posts, etc being broken with minor tweaks.
- nmatsakis: Another concern is the contract around unsafe code. E.g. if we did some GC hooks, might subtlely break existing unsafe code.
- wycats: 2.0.