Core team meeting 2015-05-06 (governance RFC, forget/leak/RcGuard, subteam setup)

aturon · 2015-05-07T17:02:42.003Z

rust-lang/meeting-minutes/blob/master/core-team/meeting-2015-05-06.md

# Attending

- aturon, nmatsakis, pcwalton, brson, acrichto, huon

# Agenda

* Governance RFC (aturon)
* mem::forget and friends (everyone)
* Subteams (aturon)

# Governance RFC

It's been in a "final comment period" for a week, there seems to be a strong consensus. We are going to merge!

# mem::forget

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

Niko's blog post laid out a perspective on the tradeoffs of various alternatives in detail (including the mem::forget, Leak, and RcGuard RFCs). This post represents the consensus from within the core team on this issue.

This file has been truncated. show original

bluss · 2015-05-07T17:38:51.524Z

The mem::forget RFC sets a bad precedent. I understand that we need a decision, the decision taken is one I’m totally ok with, but that RFC author did not engage with any suggested improvements to the RFC. No amendments at all (unless they are invisible), and no responses to any of the in-line text suggestions.

Core member posts text, waits three weeks, text accepted. This is not in the spirit of the RFC process, which tells us to build consensus and integrate feedback.

You should be more careful with the most important RFCs.

aturon · 2015-05-07T17:46:37.510Z

bluss:

Core member posts text, waits three weeks, text accepted. This is not in the spirit of the RFC process, which tells us to build consensus and integrate feedback.

While I take your point, I think it’s also a bit overstated. The RFC garnered an enormous amount of comments, and the author was very active in the discussion. The vast majority of discussion and consensus-building was about whether to go in this overall direction, or in the direction of Leak or RcGuard. I think it’s fair to say that that was primarily what the debate was about?

Looking at the inline comments, the one that I think most demands response is the question about what guarantees we do provide about destructor execution. But I think that’s a separable concern, having made the big decision about whether to allow Rc-cycle-style leaks. I think it would be best addressed in a discuss thread or separate RFC.

aturon · 2015-05-07T17:50:54.145Z

Also, for what it’s worth, the transition to subteams and the final comment period, which should happen in the next few weeks, should go a long way toward protecting against this: if an RFC enters its final comment period but some existing comments have fallen by the wayside, that’s a chance for people to bring them back up and make sure they get addressed.

nrc · 2015-05-07T20:48:36.745Z

Just noting my disapproval of discussing the subteams here and not at the weekly meeting. It’s not clear to me why it had to be done here. Glad we’re making progress on it though.

Manishearth · 2015-05-07T22:33:54.833Z

Because when discussing people, it’s sometimes best to keep it private whenever possible. Technical discussions are all good, but it’s harder to discuss people openly in a public forum; nor should the core team have to.

nrc · 2015-05-09T03:49:32.210Z

The weekly team meeting is not a public forum, it is just a slightly larger group.

Manishearth · 2015-05-09T04:45:47.710Z

I mean that the minutes are public (and some of the people being discussed may be present in the weekly meeting)

nrc · 2015-05-09T06:04:23.145Z

Not every issue is minuted, we’ve skipped minuting of sensitive issues in the past. Some of the people being discussed will be at the core team meeting too.

Manishearth · 2015-05-09T15:01:51.959Z

Ah okay. Then I guess it could have been discussed in the weekly meeting too. shrug

aturon · 2019-03-25T08:24:26.223Z

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.