Skip to content
This repository has been archived by the owner on Oct 9, 2018. It is now read-only.

Latest commit

 

History

History
104 lines (85 loc) · 4.49 KB

meeting-2015-05-13.md

File metadata and controls

104 lines (85 loc) · 4.49 KB

Attending

  • aturon, nmatsakis, pcwalton, brson, acrichto, steveklabnik

Agenda

RFCs: https://etherpad.mozilla.org/rust-rfc-planning

1.0 announcement

Largely in good shape, hoping to post a PR early on to get some additional feedback.

Subteam status report

  • Lots of positive response to invites so far
  • Moderation team:
    • Manish is taking lead in organizing, off and running, seems great
    • Probably will set up some infrastructure next week
  • Waiting till next week to really get things started with other subteams
  • Make discuss tags (subteam/foo, subteam/bar)
  • Use GH teams for subteams as well (allows @-mentioning the entire subteam)
  • Announce roster via a discuss post + web page

Governance web page

  • Used to have a page on the wiki for the core team
  • We need a page more generally talking about the subteam rosters, etc, along the lines of https://jquery.org/team/

Security policy

  • There exists a "best practices" template used by many projects
  • Encourage responsible disclosure
    • contacting appropriate person
    • prepare fix, announce together with vulnerability
    • users need something to subscribe to so they know to update
  • Want roughly 2-5 people manning the security team
    • Have access to the reporting email address
    • Must respond in 1-2 days acknowledging the report
    • Regular communication with reporter
  • We'll post an initial draft of the policy to internals for discussion, get something up on the web page before 1.0
  • Perhaps a follow-up RFC to discuss what precisely constitutes a security vulnerability

Semver for the language

  • Niko has been prepping an RFC touching on the interaction between language changes and semver (a complement to the API evolution RFC)
  • Covers: what are breaking changes for the language, and which of them can be considered in a minor release?
  • Current proposal: the only breaking changes we would consider are soundness-related. (Soundness covers memory safety issues, but also other basic properties like trait coherence).
  • RFC describes various mitigations to lessen or eliminate impact of breakage.
  • There are other changes that are not strictly speaking backcompat, but are close: adding new keywords, tweaking shorthand/defaults. In these cases, there's still a notion of an "elaborated" source code that would not be broken. These are all local things that affect a single create internally, but don't affect its public API. Proposal is to allow opt-in via a Rust version attribute (mechanism is debatable). If it's hard to tie to a version-based opt-in, then it's probably too big a change to consider anyway.
  • Need to think about recourse for accidental breakage.

How we might mitigate impact of these changes:

  1. Identify important crates (such as those with many dependencies) and work with the crate author to correct the code as quickly as possible, ideally before the fix even lands.
  2. Work hard to ensure that the error message identifies the problem clearly and suggests the appropriate solution.
  3. Provide some annotation that allows crates to "opt out" of the stricter rule. For example, when we were working on the coherence orphan rules, we included a #[old_orphan_check] annotation that could be used to get the older semantics back. Use of this annotation should be considered deprecated.
    • While the change is still breaking, this at least makes it easy for crates to update and get back to compiling status quickly.
  4. Begin with a deprecation or other warning before issuing a hard error. In extreme cases, it might be nice to begin by issuing a deprecation warning for the unsound behavior, and only make the behavior a hard error after the deprecation has had time to circulate. This gives people more time to update their crates. However, this option may frequently not be available, because the source of a compilation error is often hard to pin down with precision
  • Bootstrapping problem: older compilers will reject new opt-out attributes
    • solution: need to reserve a space now

Action item: Niko will finish and circulate draft to core team, then that will either become pre-RFC or direct RFC PR.