- CoC stuff and related issues (pnkfelix)
- Followup from last week "Policy for PRs targeting beta vs master"
- missing stdio handles (acrichto) rust-lang/rfcs#1014
- stability and docs (acrichto) http://people.mozilla.org/~acrichton/doc/std/
- symlinks (acrichto) rust-lang/rfcs#1048
- releasing a new beta (brson)
- stability attributes as errors (brson)
brson, aturon, acrichto, pcwalton, steveklabnik, pnkfelix, nrc, huon
- pnkfelix: 1.0 issues; nonzeroing drop
- brson: starting on msvc switch, making crater usable
- nrc: DST coercions, rustfmt
- acrichto: rustdoc, bugfixes
- aturon: governance RFC, 1.1 library work, new work on conc/parallelism
- brson: make 'is' suffix an error, #22496
- brson: when do we push another beta?
- steveklabnik: needs 'scoped' fix, and acrichto's rustdoc fixes
- nrc: if we can get away with fewer then we should wait
- brson: worried about deprecation of stability attributes, not in yet
- nmatsakis: other similar problems. we still allow
_issuffixes - brson: somebody working on that? i'll take it
- brson: felix also has breaking error w/ panic! is that happening?
- pnkfelix: i'd like it to ...
- pnkfelix: switched it to a warning because of potential breakage. not sure how to feature gate the new macro I added
- nmatsakis: this might be generally useful functionality, might just make it stable
- nmataskis: I'm also working on soundness fixes that will make breaking changes. Think we need more beta pushes
- pnkfelix: question is whether we can do fewer
- aturon: what's advantage?
[missed]
- aturon: what really matters is when we do the last merge from master. after that point our updates are more in line with long term plan
- nmatsakis: from point of view of outsider it doesn't matter whether it's a merge or cherry-pick
- brson: sounds good to me
- pnkfelix: last week we discussed the beta process. steve was going to write up a proposal
- steveklabnik: worked on it, brson had some objections, will revise soon
- pnkfelix: i'm worried that we don't have the process settled after we ended the mass merges
- brson: steve you'll keep working on that
- acrichto: heads up. RFC to deprecate symlink apis and merge more platform specific apis
- aturon: even if you don't care about symlinks it's an interesting case in our approach to platform-specific apis
- acrichto: fairly common for stdio to not exist, file descriptors 0, 1, 2. RFC to turn non-existing stdio into no-ops, except for stderr. seems like a good move for windows gui apps
- pnkfelix: is there a way to query whether you are in this state?
- acrichto: not currently, but possible to add some raw api for it
- acrichto: hoping to merge by end of week
- nmatsakis: there's an rfc from japaric about A += B. doesn't need to be merged now, but it seems to be settled. Might want to take a look if you haven't already.
- brson: no backcompat issues here?
- nmatsakis: nope
http://people.mozilla.org/~acrichton/doc/std/ http://people.mozilla.org/~acrichton/doc/std/io/index.html http://people.mozilla.org/~acrichton/doc/std/vec/struct.Vec.html http://people.mozilla.org/~acrichton/doc/std/old_io/index.html rust-lang/rust#24396
- acrichto: planning differences to way we handle stability in docs. I have a branch. stability markers are going away in the docs in general, maybe not hide deprecated/unstable items, add some warnings about unstable items. idea is that docs look the same for staged_api vs non-staged_api.
- acrichto: amount of unstable items in std is so small it may not warrant hiding them all by default
- brson: what pages to look at?
- acrichto: io, vec
- brson: I think it looks nice and clean
... (background on makoh mass-closing issues) ...
- nrc: can we ban makoh from the org?
- nmatsakis: currently plan as part of larger governance rfc is to establish procedure for dealing with coc violations. prefer to have structure in place before making any calls here
- nrc: perhaps we can enforce retroactively
- aturon: why ban?
- nrc: chances of him contributing positively seems like 0%. agree with kmc we've been very soft about applying coc. strcat always left room for interpretation. in this case mahkoh was repeatedly rude, then vandalized the issue tracker. ignoring that sends the wrong signal
- aturon: (missed). if there is an ongoing problem and we commit to the process it will solve itself, doesn't need a ban right now
...
- pnkfelix: there was that event i did see. the other event, somebody on that ticket said 'can someone please close this ticket?'. makoh's response was to close then reopen it immediately. I closed the ticket, then he rage quit.
- aturon: i think he has been closing these issues for a while. not sure it's worth analyzing the exact cause
- aturon: there are others whose behavior arguably violates the coc and we have to be even-handed
...
- aturon: one thing that's happened as a result of makoh's actions is there has been a lot of community discussion about what to do about the coc. I think we've made it clear this is something we're looking at and concerned about. Yeah, we're sending bad signals right now, but we can indicate that we're planning on making changes, and will be able to start with a clear slate.
- aturon: I should be able to circulate a draft today.
- huon: github has no moderation tools. do we know if there's anything we can do?
- steveklabnik: yes, github can block people from the org
- pnkfelix: can it be temporary?
- steveklabnik: I assume they can unban
- aturon: there was a suggestion we could work around limitations with a bot that delete's banned people's coments
...
- aturon: is everyone comfortable with next steps being having public discussion about coc enforcement?
- steveklabnik: yes. want to read draft beforehand