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

Latest commit

 

History

History
114 lines (82 loc) · 3.78 KB

meeting-2015-04-29.md

File metadata and controls

114 lines (82 loc) · 3.78 KB
Raw

Agenda

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

Attending

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

mem::forget

Niko made a blog post responding to the various proposals related to leakage:

http://smallcultfollowing.com/babysteps/blog/2015/04/29/on-reference-counting-and-leaks/

TLDR is: this is subtle, there are a lot of avenues we've explored, but fundamentally the tradeoff in complexity/composability restrictions in things like Leak or making Rc 'static is not worth it for solving the relatively thin problem of scoped-like APIs.

brson asks: can you imagine doing something in the future to rule out leaks?

niko: I'm somewhat dubious. I do have some hope that we can improve scoped-like APIs in some other way (perhaps reducing rightward drift). I'm very wary of a scheme that has global ramifications on composability.

Optimize by default

rust-lang/rfcs#967

Requests Cargo/rustc optimize code by default.

  • No clear consensus on the topic.
  • Definite pitfalls on either side.
  • All configurations will be possible no matter what; this is purely a question of defaults.
  • No C/C++ compiler does -O3 by default.

Motivations to change from the status quo:

  • People doing microbenchmarks without optimization
  • Some projects want the best perf by default
  • Accidentally pushing a debug binary into production can cause a huge problem

Argument for status quo:

  • Simplest is that, the vast majority of the time you want cargo build you are doing development and want faster build time/debug info by default.
  • No matter what you do, you need both options, so it will remain possible to accidentally produce the wrong kind of binary.
  • If we tell people to type --debug most of the time, what stops them from accidentally typing that when they go to release? (iow, defaults that don't reflect most common usage may not have the desired effect).

Debug builders

rust-lang/rust#24847

  • PR to stabilize debug builders as-is.
  • Not a lot of experience using it: Is this urgent?

Lots of discussion about the exact policy for ungating features. This API seems good, but it hasn't been around very long and we're not sure how widely it's being used. In general we need a clear procedure for ungating -- perhaps something like the "final comment period" for RFCs, where we ask for feedback from people using the API/feature.

For this case, we'll talk directly to the author and perhaps do an ad hoc version of a "call for feedback" on discuss.

Security policy

Still plan to put together a policy for security vulnerabilities, etc before the 1.0 release.

There may be some core pieces, e.g. having an email address for privately raising security issues, that we can put into place immediately. But there are also more complex policy issues that we may want to put through the RFC process, like what constitutes a security issue.

Components:

  • e-mail address
  • expectations for response time
  • PGP key

Conclusion:

  • take basic steps now (and announce on discuss, together with intent for in-depth policy RFC)
  • prepare a more in-depth RFC to hammer out

Governance

  • RFC thread is quiet, seems to have reached a kind of consensus.
  • Seems reasonable to start a final comment period.
  • How should we... actually do that?
    • Ultimately some kind of dashboard would be ideal
      • perhaps feature oriented
    • For now let's do a discuss post with a new tag for "Announcements"

1.0