Stream: t-compiler

Topic: design meeting 2020.04.23 compiler-team#267


pnkfelix (Apr 24 2020 at 13:58, on Zulip):

Hi @T-compiler/meeting ; we will be starting the steering meeting regarding compiler-team#267, Standard library implementation ownership, in about two minutes

pnkfelix (Apr 24 2020 at 14:03, on Zulip):

Go ahead and add a :wave: emoji above to show that you are here!

pnkfelix (Apr 24 2020 at 14:03, on Zulip):

We will start off with five minutes for ...

pnkfelix (Apr 24 2020 at 14:03, on Zulip):

Announcements

pnkfelix (Apr 24 2020 at 14:07, on Zulip):

I guess its a good thing when there are no announcements a day after a release. :)

simulacrum (Apr 24 2020 at 14:08, on Zulip):

I did manage to bork the beta (we're at 1.44.0-beta.752 somehow), but that's not really an announcement...

pnkfelix (Apr 24 2020 at 14:09, on Zulip):

wow; like, that denotes that there were 753 versions on the beta channel before this one?

pnkfelix (Apr 24 2020 at 14:09, on Zulip):

such progress!

pnkfelix (Apr 24 2020 at 14:10, on Zulip):

well okay, lets move on to the topic at hand

pnkfelix (Apr 24 2020 at 14:11, on Zulip):

the proposal is that our team, in addition to its existing responsibilities (design and implementation of the rustc compiler) would also take on maintenance duties for the standard library/ies (everything that feeds into libstd)

simulacrum (Apr 24 2020 at 14:12, on Zulip):

(libtest, probably, but yes)

pnkfelix (Apr 24 2020 at 14:12, on Zulip):

and T-libs would reduce its scope to just being about the design of libstd

pnkfelix (Apr 24 2020 at 14:13, on Zulip):

I did think that this sentence from the motivation was pretty interesting: "The team (T-libs) selects for people with diverse library design experience, which means members tend to have active library projects outside the standard library; this is unlike the compiler team for whom their team role is usually their dominant project."

oli (Apr 24 2020 at 14:13, on Zulip):

So where's the boundary? Any PR touching creating new stable APIs or stable API docs? Or Any PR touching public APIs or public API's docs?

oli (Apr 24 2020 at 14:13, on Zulip):

Because I totally see the point that libstd internals are an impl detail of the compiler

oli (Apr 24 2020 at 14:14, on Zulip):

after all, all functions could just invoke intrinsics

oli (Apr 24 2020 at 14:14, on Zulip):

instead of having a body

pnkfelix (Apr 24 2020 at 14:14, on Zulip):

exactly

pnkfelix (Apr 24 2020 at 14:14, on Zulip):

as for the question of boundary

simulacrum (Apr 24 2020 at 14:14, on Zulip):

yeah, so the idea is that t-libs would be "called in" for any "rustdoc visible" change, basically, though of course similar to lang it's often nice to ping/ask/etc for other changes too, if they affect "API" at a lower level (e.g. performance tradeoffs)

pnkfelix (Apr 24 2020 at 14:14, on Zulip):

I was assuming that both creation of new public APIs and changes to public API's (both in stable and unstable/nightly) would remain the domain of T-libs

David Tolnay (Apr 24 2020 at 14:15, on Zulip):

historically the libs team or a subset has been responsible for "the standard library" among other things, which encompasses:

David Tolnay (Apr 24 2020 at 14:15, on Zulip):

the last is the only one i think needs to remain libs' role

pnkfelix (Apr 24 2020 at 14:16, on Zulip):

Hmm. approving stabilization PR's might still need to remain under T-libs

pnkfelix (Apr 24 2020 at 14:16, on Zulip):

or at least, I'm not sure if I would be comfortable trying to determine when an API was "safe" to stabilize ...

David Tolnay (Apr 24 2020 at 14:16, on Zulip):

well, if the tracking issue has a finished FCP, does libs need to be involved in the stabilization PR?

pnkfelix (Apr 24 2020 at 14:16, on Zulip):

oh maybe I misunderstand

simulacrum (Apr 24 2020 at 14:17, on Zulip):

basically at a high level, libs becomes like lang -- no direct involvement in PR approval

pnkfelix (Apr 24 2020 at 14:17, on Zulip):

I see, so you're just talking about the PR that implements the stabilization itself

David Tolnay (Apr 24 2020 at 14:17, on Zulip):

right

pnkfelix (Apr 24 2020 at 14:17, on Zulip):

This sounds fine to me. I mean, obviously its problematic to just take on more work

pnkfelix (Apr 24 2020 at 14:18, on Zulip):

but I think we are learning better how to scale our existing processes

pnkfelix (Apr 24 2020 at 14:18, on Zulip):

thanks in no small part to our various WG's

simulacrum (Apr 24 2020 at 14:19, on Zulip):

(and at least part of the intent is that we'd likely want to spin up something like std-contributors or so, though perhaps not immediately; it's unclear whether it need be a separate group though from compiler-contributors)

pnkfelix (Apr 24 2020 at 14:19, on Zulip):

So, here's a potentially silly question

pnkfelix (Apr 24 2020 at 14:19, on Zulip):

Obviously a change in scope like this means that T-compiler is a bit of a misnomer

pnkfelix (Apr 24 2020 at 14:19, on Zulip):

would it be ... a nightmare ... to try to rename the team to T-implementation or something?

pnkfelix (Apr 24 2020 at 14:20, on Zulip):

I personally would be fine with just leaving the name as is

oli (Apr 24 2020 at 14:20, on Zulip):

:shrug: I'm feeling like the compiler is the implementation

pnkfelix (Apr 24 2020 at 14:20, on Zulip):

and just acknowledge it as a historical artifact

simulacrum (Apr 24 2020 at 14:20, on Zulip):

I think I would hold off on renaming things at least for a while

oli (Apr 24 2020 at 14:20, on Zulip):

and if "the compiler" contains some libstd source... again :shrug:

pnkfelix (Apr 24 2020 at 14:20, on Zulip):

@oli but it isn't? The stdlib is distinct from the compiler. I mean, yes we could have intrinsics for everything

simulacrum (Apr 24 2020 at 14:21, on Zulip):

there's a good chance in my mind that we eventually create a parent team here -- e.g. we'd still have a compiler team but there'd be a "rust source" team or something

pnkfelix (Apr 24 2020 at 14:21, on Zulip):

so, lets take an example: The choice of what data structure for the standard HashMap

pnkfelix (Apr 24 2020 at 14:21, on Zulip):

that is an implementation detail (right?)

simulacrum (Apr 24 2020 at 14:21, on Zulip):

yes, though plausibly affects available APIs :)

pnkfelix (Apr 24 2020 at 14:22, on Zulip):

I mean, some hashmap designs would require multiple hash functions (e.g. cuckoo hashing)

pnkfelix (Apr 24 2020 at 14:22, on Zulip):

but my point is, I do think that the hashmap internals are largely independent from the compiler internals

pnkfelix (Apr 24 2020 at 14:23, on Zulip):

and I'd like to figure out a way to advertise this to volunteers

pnkfelix (Apr 24 2020 at 14:23, on Zulip):

I guess the forge will just tell them where to go

pnkfelix (Apr 24 2020 at 14:24, on Zulip):

or people will; i.e. T-libs can tell people if they are interested in helping with implementation, then they should come on over and talk to us over here

pnkfelix (Apr 24 2020 at 14:25, on Zulip):

Anyway

pnkfelix (Apr 24 2020 at 14:25, on Zulip):

let me ask a more fundamental question

pnkfelix (Apr 24 2020 at 14:25, on Zulip):

Does anyone present think that this is a bad idea?

David Tolnay (Apr 24 2020 at 14:26, on Zulip):

i think "taking on more work" is a legitimate concern that we may want to try to settle

Esteban Küber (Apr 24 2020 at 14:26, on Zulip):

I agree with the rationale in the original proposal, but I am worried about the t-compiler's bandwith

David Tolnay (Apr 24 2020 at 14:26, on Zulip):

maybe by trying the change for a couple months only and reevaluating

pnkfelix (Apr 24 2020 at 14:27, on Zulip):

I assume the current labels do not distinguish T-libs implementation issues from T-libs design issues, right?

simulacrum (Apr 24 2020 at 14:27, on Zulip):

we have very few implementation issues

pnkfelix (Apr 24 2020 at 14:27, on Zulip):

well that's good

David Tolnay (Apr 24 2020 at 14:27, on Zulip):

pnkfelix no but I'm happy to share links to implementation issues, i have a list

simulacrum (Apr 24 2020 at 14:27, on Zulip):

(to some extent, C-feature-request/accepted is design)

pnkfelix (Apr 24 2020 at 14:27, on Zulip):

@David Tolnay how do you track them?

David Tolnay (Apr 24 2020 at 14:28, on Zulip):

just ran through "is:pr assignee:dtolnay" last night

pnkfelix (Apr 24 2020 at 14:28, on Zulip):

@simulacrum I see, so search for T-libs on github but filter out the C-feature-request ones?

pnkfelix (Apr 24 2020 at 14:28, on Zulip):

Heh, all implementation issues are assigned to you, @David Tolnay ?

simulacrum (Apr 24 2020 at 14:28, on Zulip):

@pnkfelix yeah, I think that's a good heuristic though not perfect

pnkfelix (Apr 24 2020 at 14:29, on Zulip):

so as a quick example

pnkfelix (Apr 24 2020 at 14:29, on Zulip):

"Implement TryInto<CString> for str and String" #71448

pnkfelix (Apr 24 2020 at 14:29, on Zulip):

this would remain a T-libs design issue, right?

pnkfelix (Apr 24 2020 at 14:29, on Zulip):

because that's a public API change?

simulacrum (Apr 24 2020 at 14:29, on Zulip):

yeah, it was wrongly tagged

pnkfelix (Apr 24 2020 at 14:29, on Zulip):

:)

DPC (Apr 24 2020 at 14:30, on Zulip):

for implementing easy stuff, i can get it off the team by assigning it to newcomers who are willing to contribute. It adds a bit of review overhead on the team though

pnkfelix (Apr 24 2020 at 14:30, on Zulip):

just want to double check my understanding

simulacrum (Apr 24 2020 at 14:30, on Zulip):

if it affects rustdoc, it's definitely design, basically

David Tolnay (Apr 24 2020 at 14:30, on Zulip):

if it needs FCP, it's design, which this one does

pnkfelix (Apr 24 2020 at 14:31, on Zulip):

And likewise, C-tracking-issues are also T-libs design ?

pnkfelix (Apr 24 2020 at 14:31, on Zulip):

or does that depend on context?

simulacrum (Apr 24 2020 at 14:31, on Zulip):

sort of, the work within them (e.g. if t-libs accepts an RFC) is not design-y in nature, but the stabilization and decision making for unanswered questions and such likely is t-libs

David Tolnay (Apr 24 2020 at 14:31, on Zulip):

yes, at least ones that track something unstable that will need FCP to stabilize

simulacrum (Apr 24 2020 at 14:31, on Zulip):

basically same as t-lang tracking issues

pnkfelix (Apr 24 2020 at 14:32, on Zulip):

okay

pnkfelix (Apr 24 2020 at 14:32, on Zulip):

this is all in service of me trying to get an actual count

pnkfelix (Apr 24 2020 at 14:33, on Zulip):

"is:open is:issue label:T-libs -label:C-feature-request -label:C-tracking-issue " says 375 open issues

pnkfelix (Apr 24 2020 at 14:33, on Zulip):

that's actually quite promising

pnkfelix (Apr 24 2020 at 14:33, on Zulip):

(I know that @simulacrum already said we have very few issues; I just wanted to see for myself)

DPC (Apr 24 2020 at 14:34, on Zulip):

some of those are just a stabilisation away from being closed

pnkfelix (Apr 24 2020 at 14:34, on Zulip):

I might also filger out the ones that have T-doc tagged as well

pnkfelix (Apr 24 2020 at 14:35, on Zulip):

okay, so my guess is that we might be adding between 200 and 300 issues to our plate

pnkfelix (Apr 24 2020 at 14:36, on Zulip):

most of which have no P-label

pnkfelix (Apr 24 2020 at 14:36, on Zulip):

(which is not surprising since its largely T-compiler that makes use of the P-label)

simulacrum (Apr 24 2020 at 14:37, on Zulip):

essentially all t-libs issues are p-low, since they're just feature requests -- they're not stuff we "must do" unlike the typical t-compiler bug

pnkfelix (Apr 24 2020 at 14:37, on Zulip):

or rather, the ones that are P-high or worse tend to get fixed quickly I imagine, right?

pnkfelix (Apr 24 2020 at 14:38, on Zulip):

that is, its not that all T-libs issues that are filed are P-low

pnkfelix (Apr 24 2020 at 14:38, on Zulip):

just that it tends to be easier to fix important issues there

David Tolnay (Apr 24 2020 at 14:38, on Zulip):

i've been thinking more from the perspective of PRs than issues

David Tolnay (Apr 24 2020 at 14:39, on Zulip):

most of the PRs related to libs issues are not made by team members

David Tolnay (Apr 24 2020 at 14:39, on Zulip):

PRs come in at some rate and need attention

pnkfelix (Apr 24 2020 at 14:39, on Zulip):

okay, I was wondering why you were treating that as your query

pnkfelix (Apr 24 2020 at 14:40, on Zulip):

The main problem there is that the current T-compiler team is not necessarily an expert in the stdlibs code

pnkfelix (Apr 24 2020 at 14:40, on Zulip):

so the members may not all be comfortable with reviewing PR's against arbitrary portions of the stdlib

pnkfelix (Apr 24 2020 at 14:40, on Zulip):

but we can try it and see

David Tolnay (Apr 24 2020 at 14:40, on Zulip):

maybe this is colored by experience at Facebook where any engineer can approve changes to anywhere in the codebase, but for something like https://github.com/rust-lang/rust/pull/68033 "Don't use f64 shims for f32 cmath functions on non 32-bit x86 MSVC" as a libs member I really have no more ability to review this than any competent Rust programmer at my company would have; it's not like I had any context on those shims before seeing the PR

David Tolnay (Apr 24 2020 at 14:41, on Zulip):

so it may also be interesting to consider whether we may be able to harness review bandwidth from companies

David Tolnay (Apr 24 2020 at 14:41, on Zulip):

possibly a separate discussion

pnkfelix (Apr 24 2020 at 14:41, on Zulip):

So let me try to explicitly tease out the different concerns here

pnkfelix (Apr 24 2020 at 14:41, on Zulip):
  1. There is an influx (and backlog?) of PR's to the stdlib
pnkfelix (Apr 24 2020 at 14:42, on Zulip):

that need review or at least some sort of handling

pnkfelix (Apr 24 2020 at 14:42, on Zulip):
  1. There are a set of issues filed against the stdlib
pnkfelix (Apr 24 2020 at 14:42, on Zulip):

that need handling (e.g. prioritization)

pnkfelix (Apr 24 2020 at 14:42, on Zulip):
  1. There are procedural matters that need to be followed up on
pnkfelix (Apr 24 2020 at 14:43, on Zulip):

(e.g. filing of stabilization PR's for FCP'ed stuff)

pnkfelix (Apr 24 2020 at 14:43, on Zulip):

That's everything I can think of... anything else?

RalfJ (Apr 24 2020 at 14:43, on Zulip):

oli said:

after all, all functions could just invoke intrinsics

(intrinsics are also t-lang territory though, to some extend ;) )

RalfJ (Apr 24 2020 at 14:44, on Zulip):

if you are looking for examples for implementation-only libs PRs, I think most of https://github.com/rust-lang/rust/pulls?q=is%3Apr+author%3Assomers+is%3Aclosed are of that kind -- ssomer's BTree work seems to fit squarely into what T-libs would hand off to T-compiler with this change, if my reading is correct.

David Tolnay (Apr 24 2020 at 14:45, on Zulip):

"There are a set of issues filed against the stdlib that need handling (e.g. prioritization)" -- we don't do much of this; things get fixed when it is important enough to someone outside the team to fix it

David Tolnay (Apr 24 2020 at 14:45, on Zulip):

"There are procedural matters that need to be followed up on (e.g. filing of stabilization PR's for FCP'ed stuff)" -- same

pnkfelix (Apr 24 2020 at 14:47, on Zulip):

@David Tolnay so for items 2. and 3., you are saying that T-libs already does not do such activity

David Tolnay (Apr 24 2020 at 14:48, on Zulip):

right

pnkfelix (Apr 24 2020 at 14:48, on Zulip):

I was assuming that was due to a lack of developer resources

pnkfelix (Apr 24 2020 at 14:48, on Zulip):

but perhaps you are saying that it is not a worthwhile activity?

pnkfelix (Apr 24 2020 at 14:49, on Zulip):

(since, if it were worthwhile, then an outside contributor would provide it?)

David Tolnay (Apr 24 2020 at 14:49, on Zulip):

it's both, but the worthwhile things do tend to get picked up

pnkfelix (Apr 24 2020 at 14:50, on Zulip):

okay. My own preference would be to try to figure out how to actually resolve the issues that have been filed

pnkfelix (Apr 24 2020 at 14:50, on Zulip):

since the issue database continues to grow

pnkfelix (Apr 24 2020 at 14:51, on Zulip):

but we certainly haven't yet figured out how to deal with the backlog within T-compiler either

David Tolnay (Apr 24 2020 at 14:51, on Zulip):

i think it's natural that the issue database would grow

DPC (Apr 24 2020 at 14:51, on Zulip):

(i am looking at getting some of the older issues closed)

pnkfelix (Apr 24 2020 at 14:51, on Zulip):

so I'm willing to agree that item 2 is treated roughly the same by T-libs and T-compiler

pnkfelix (Apr 24 2020 at 14:52, on Zulip):

We're nearing the hour

pnkfelix (Apr 24 2020 at 14:52, on Zulip):

there's one thing I wanted to try to dive into a little more carefully

pnkfelix (Apr 24 2020 at 14:53, on Zulip):

someone (cannot find the quote right now) earlier said

pnkfelix (Apr 24 2020 at 14:53, on Zulip):

maybe we should just try this for a few months

pnkfelix (Apr 24 2020 at 14:53, on Zulip):

The main issue there

pnkfelix (Apr 24 2020 at 14:53, on Zulip):

well, maybe it doesn't matter

pnkfelix (Apr 24 2020 at 14:53, on Zulip):

I was going to say

pnkfelix (Apr 24 2020 at 14:53, on Zulip):

the main issue there is that I would think that a natural consequence of this

pnkfelix (Apr 24 2020 at 14:53, on Zulip):

is that we would apply the T-compiler protocols

pnkfelix (Apr 24 2020 at 14:54, on Zulip):

to the libs implementation issues

pnkfelix (Apr 24 2020 at 14:54, on Zulip):

so we would want some way to incorporate handling them

pnkfelix (Apr 24 2020 at 14:54, on Zulip):

into our existing systems

pnkfelix (Apr 24 2020 at 14:54, on Zulip):

that means, to me, we either 1. start tagging them as T-compiler

pnkfelix (Apr 24 2020 at 14:55, on Zulip):

or 2. our team starts surveying the things tagged as T-libs

pnkfelix (Apr 24 2020 at 14:55, on Zulip):

or 3. we allocate a new label

pnkfelix (Apr 24 2020 at 14:55, on Zulip):

if we are going to do this on some sort of trial period

pnkfelix (Apr 24 2020 at 14:55, on Zulip):

then (1.) is bad

simulacrum (Apr 24 2020 at 14:55, on Zulip):

I would lean towards a new label; seems the easiest and most practical

pnkfelix (Apr 24 2020 at 14:55, on Zulip):

I'm not a huge fan of (2.) unless we figure out a good way to differentiate the design stuff from impl stuff

David Tolnay (Apr 24 2020 at 14:55, on Zulip):

+1 for new label, they would be labelled T-libs + implementation

pnkfelix (Apr 24 2020 at 14:56, on Zulip):

so yes, I think I agree about a new label

pnkfelix (Apr 24 2020 at 14:57, on Zulip):

maybe libs-implementation (or just libs-impl) ?

pnkfelix (Apr 24 2020 at 14:57, on Zulip):

I don't know why I'm shying away from "implementation"

DPC (Apr 24 2020 at 14:57, on Zulip):

T-implementation?

simulacrum (Apr 24 2020 at 14:57, on Zulip):

libs-impl seems good

David Tolnay (Apr 24 2020 at 14:57, on Zulip):

one failure mode I would flag is that y'all start doing way more work on libs issues than libs has ever done, and conclude at the end of the trial period that you don't have bandwidth for it, but would totally have had bandwidth for the work that libs is actually trying to hand off

simulacrum (Apr 24 2020 at 14:57, on Zulip):

shorter, anyway, which is nice in some sense

pnkfelix (Apr 24 2020 at 14:57, on Zulip):

for some reason I want to embed the detail that this is about libs too

pnkfelix (Apr 24 2020 at 14:58, on Zulip):

@David Tolnay yes I am inferring that was not your intention

pnkfelix (Apr 24 2020 at 14:59, on Zulip):

which is why it was good we teased out the 3 potential concerns above

pnkfelix (Apr 24 2020 at 14:59, on Zulip):

So for now

pnkfelix (Apr 24 2020 at 14:59, on Zulip):

Lets maybe plan it this way

pnkfelix (Apr 24 2020 at 14:59, on Zulip):

Officially, what we're doing is taking on some additional review duties

pnkfelix (Apr 24 2020 at 14:59, on Zulip):

PR's can start being marked with libs-impl

pnkfelix (Apr 24 2020 at 15:00, on Zulip):

and if they are so marked, then they end up in our pool of things to review

David Tolnay (Apr 24 2020 at 15:00, on Zulip):

sounds great

pnkfelix (Apr 24 2020 at 15:00, on Zulip):

but at the same time

pnkfelix (Apr 24 2020 at 15:00, on Zulip):

I'm interpreting all of this

pnkfelix (Apr 24 2020 at 15:01, on Zulip):

as a sign that you all do not object to us trying to apply priority labels and such

pnkfelix (Apr 24 2020 at 15:01, on Zulip):

to T-libs issues that are solely about implementation

David Tolnay (Apr 24 2020 at 15:01, on Zulip):

no objection

David Tolnay (Apr 24 2020 at 15:01, on Zulip):

for calibration, here is a diverse representative set of PRs that i think would be libs-impl

pnkfelix (Apr 24 2020 at 15:01, on Zulip):

Okay. In the past, I have avoided attaching P-labels to non T-compiler issues

pnkfelix (Apr 24 2020 at 15:01, on Zulip):

because the interpretation of the P-labels was not standardized across teams

pnkfelix (Apr 24 2020 at 15:02, on Zulip):

I think we can also feel free to tag issues as libs-impl if we believe they are not design issues, just issues filed against implementation details

pnkfelix (Apr 24 2020 at 15:02, on Zulip):

But that task is not officially what you are asking us to do

David Tolnay (Apr 24 2020 at 15:03, on Zulip):

libs-impl on issues gets weird because design issues need implementation work too

David Tolnay (Apr 24 2020 at 15:03, on Zulip):

like in the Result::as_deref_ok tracking issue we decide to rename to as_deref, it's now a libs-impl issue?

pnkfelix (Apr 24 2020 at 15:03, on Zulip):

hmm

pnkfelix (Apr 24 2020 at 15:03, on Zulip):

the issue remains a design/API issue

pnkfelix (Apr 24 2020 at 15:04, on Zulip):

the PR that implements the rename could be libs-impl

pnkfelix (Apr 24 2020 at 15:04, on Zulip):

Right?

pnkfelix (Apr 24 2020 at 15:04, on Zulip):

I'm more trying to figure out good ways , if I'm reviewing the issue database

David Tolnay (Apr 24 2020 at 15:04, on Zulip):

sure, but nothing would be tracking that the issue requires implementation work

pnkfelix (Apr 24 2020 at 15:04, on Zulip):

Well don't all open issues require implementation work, in some sense?

pnkfelix (Apr 24 2020 at 15:05, on Zulip):

anyway I'm rambling

pnkfelix (Apr 24 2020 at 15:05, on Zulip):

and we're over our hour

pnkfelix (Apr 24 2020 at 15:05, on Zulip):

action items:

pnkfelix (Apr 24 2020 at 15:05, on Zulip):

Allocate a new libs-impl label

pnkfelix (Apr 24 2020 at 15:05, on Zulip):

Start tagging PR's with libs-impl

pnkfelix (Apr 24 2020 at 15:05, on Zulip):

and then T-compiler people should feel free to review such PR's.

pnkfelix (Apr 24 2020 at 15:06, on Zulip):

(we'll have to see about auto-assignment of the reviews)

pnkfelix (Apr 24 2020 at 15:06, on Zulip):

Sound okay everyone?

David Tolnay (Apr 24 2020 at 15:06, on Zulip):

if an implementation PR is assigned to me, who do I reassign to?

pnkfelix (Apr 24 2020 at 15:06, on Zulip):

Anyway thanks to everyone in @T-compiler/meeting for attending!

Wesley Wiser (Apr 24 2020 at 15:06, on Zulip):

A summary of the decision points from this meeting would also be very helpful!

pnkfelix (Apr 24 2020 at 15:07, on Zulip):

David Tolnay said:

if an implementation PR is assigned to me, who do I reassign to?

I don't know yet

simulacrum (Apr 24 2020 at 15:07, on Zulip):

@David Tolnay I think we should update highfive to not do so, but for now, let's tentatively just say reassign to me perhaps? I can try to help direct it to people (or review it) and we can work with wg-triage to figure that out more precisely

David Tolnay (Apr 24 2020 at 15:08, on Zulip):

thanks, sgtm

LeSeulArtichaut (Apr 24 2020 at 15:08, on Zulip):

pnkfelix said:

would it be ... a nightmare ... to try to rename the team to T-implementation or something?

Let's ask the Rustc Dev Guide WG x)

(I wanted to do that joke earlier but I didn't want to disrupt the meeting :sweat_smile:)

David Tolnay (Apr 24 2020 at 15:08, on Zulip):

pnkfelix said:

Well don't all open issues require implementation work, in some sense?

a tracking issue only sometimes needs implementation work (when a change has been requested by the team, or when FCP is done)

David Tolnay (Apr 24 2020 at 15:09, on Zulip):

the rest of the time there's no work to be done beyond collecting experience

pnkfelix (Apr 24 2020 at 15:10, on Zulip):

(Okay I've created the libs-impl label. Feel free to object to my color choice.)

Last update: Jun 04 2020 at 17:35UTC