meeting-2016-01-20.md

Agenda 2016-01-20

• moderation report (aturon)
• jemalloc (acrichto, aturon)
• coc modifications

Moderation Report

• pnkfelix prepared a high-level summary of the moderation actions since moderation team was created so that we can get a high-level feeling for how things have been going.
• Report just records number of incidents reported and number of actions taken.
• Numbers are quite low.

jemalloc

• acrichto:
  • Lots of problems with jemalloc lately.
  • MSVC bugs.
  • What ends up happening is that our C compiler tends to be a bit different and lead to portability issues.
  • jemalloc has always made the Hello, World binary much larger.
  • Tempting to turn off jemalloc by default, but make it possible to easily enable it.
  • Tracking down problems triggered by jemalloc is getting to be a major time sink.
• pcwalton: Servo depends on jemalloc for performance. Continued support for jemalloc is important, and it needs to be something that can easily be done through cargo.
• acrichto: the allocator crate ought to be perfect for this, you should be able to impose a global allocator after the fact.
• wycats: regarding Cargo compiler flags, I want to propose to loosen the current strategy, except that our compiler flag story is not as good as our stability story -- I feel nervous about allowing arbitrary compiler flags because a lot of them are known to be unstable, but still shipping in stable. I would like if we can solve that and just let cargo supply arbitrary flags.
• aturon: if servo is really depending on it, it's depending on it to work. If we remove it and stop testing it, it's going to break quickly, right? Wouldn't that cause a problem for Servo? Maybe we can just test it only on a smaller set of platforms.
• acrichto: the deadlock affected linux and OS X, and there have been 2 windows bugs so far, so there isn't really any platform immune to these issues.
• acrichto: but of course jemalloc is a robust, well-tested library, but we seem to be hitting a lot of bugs somehow.
• acrichto: maybe we just need to lag behind more?
• wycats: won't that irritate Debian and packagers?
• wycats: presumably when jemalloc is stable and rock-solid, more distros will ship it
• ...
• acrichto: my true goal is to stop having these issues; I want to make it very easy to switch back to system allocator and stop debugging jemalloc on windows :)
• pcwalton: system alloc by default seems correct in a lot of ways
• wycats: but it doesn't remove need to test it, if we want it to be supported
• brson: if we go route of system alloc by default, though, I'd want to jettison jemalloc from tree, and make it all in cargo
• brson: a big part of the problem is how it is integrated
• pcwalton: but someone needs to run cI
• brson: which then gets easier because we only need to support a limited number of platforms
• acrichto: putting it in cargo would make it easy, but to work, it needs to hook into the custom allocators we have today, which is far off from stabilization, so that would mean moving jemalloc to a nightly only feature
• acrichto: so we could either make it nightly only or we could stabilize the "alloc jemalloc" crate that we ship, so that you can pick jemalloc in your crate
• wycats: that doens't address CI?
• acrichto: we'd still have to support it
• wycats: could we make it external for nightly but ship it as part of distribution in stable?
• acrichto: hard from a distribution point of view
• brson: why can't we make jemalloc nightly only? servo certainly wouldn't mind.
• pcwalton: we would want to check effect on benchmarks. People judge performance of Rust by that, for better or worse.
• wycats: in general, adding highly important nightly only features is a risk
• aturon: feels like we're all roughly on same page in terms of where we want to be in the long run, but:
  • maintain status quo for time being?
  • keep pushing on allocator stabilization?

Code of Conduct

• Discussed code of conduct changes, leading to https://users.rust-lang.org/t/recent-clarification-to-the-code-of-conduct/4390