Stream: t-compiler/meetings

Topic: [steering meeting] 2020-05-15 compiler-team#290


pnkfelix (May 15 2020 at 14:01, on Zulip):

Hi @T-compiler/meeting (add a :wave: to show you're here)

pnkfelix (May 15 2020 at 14:02, on Zulip):

So today's topic is the survey results

pnkfelix (May 15 2020 at 14:02, on Zulip):

I guess this hackmd is one place to start. At the very least, its where I decided to put the Announcements for today's meeting. :smile:

pnkfelix (May 15 2020 at 14:03, on Zulip):

speaking of which

pnkfelix (May 15 2020 at 14:03, on Zulip):

Five minutes now for ...

pnkfelix (May 15 2020 at 14:03, on Zulip):

Announcements

pnkfelix (May 15 2020 at 14:03, on Zulip):
simulacrum (May 15 2020 at 14:03, on Zulip):

Rust is 5: https://blog.rust-lang.org/2020/05/15/five-years-of-rust.html :)

Santiago Pastorino (May 15 2020 at 14:04, on Zulip):

pnkfelix said:

about triaging meeting, the idea would be to just jump and have next one next thursday, right?

pnkfelix (May 15 2020 at 14:05, on Zulip):

that was my plan, yes

pnkfelix (May 15 2020 at 14:05, on Zulip):

(I just figured I should announce the unilateral approvals somewhere)

pnkfelix (May 15 2020 at 14:06, on Zulip):

okay so as for today's meeting

pnkfelix (May 15 2020 at 14:06, on Zulip):

the linked hackmd has a lot of snippets from the surveys, but I attempted to condense it into a high-level summary of the biggest issues that niko and I noted when reviewing the results

pnkfelix (May 15 2020 at 14:07, on Zulip):

High Level

  1. long standing problems going unaddressed (or hard to track progress thereof; lack of status updates)
  2. worker drain and lack of bandwidth.
  3. lack of focus: triage meeting goes into weeds; our chat is forked; our team is too broad
  4. change-to-test cycle is too long (more broadly, everything is too high latency)
  5. hard to find correct usage patterns; communal knowledge is not shared well
nikomatsakis (May 15 2020 at 14:07, on Zulip):

my minor nit is that I think lack of focus can also be interpreted with respect to the first problem

nikomatsakis (May 15 2020 at 14:08, on Zulip):

(i.e., maybe that's part of the reason why, doing too many things at once)

pnkfelix (May 15 2020 at 14:09, on Zulip):

yes. Some discussion with @Wesley Wiser led to them putting it this way:

1. we do have "internal" updates but a lot of that happens in various GitHub issues, PRs, things that like which unless you're very active in the project, you don't see and
2. it's hard to find longer-term planning information.

pnkfelix (May 15 2020 at 14:10, on Zulip):

/me gives up on trying to make the markdown processor produce an <ol>

nikomatsakis (May 15 2020 at 14:10, on Zulip):

=)

pnkfelix (May 15 2020 at 14:11, on Zulip):

so in terms of how to spend this meeting

pnkfelix (May 15 2020 at 14:11, on Zulip):

we thought we might just all try to brain storm on ways to address the issues above

pnkfelix (May 15 2020 at 14:11, on Zulip):

or at least, I thought that could be useful

nikomatsakis (May 15 2020 at 14:12, on Zulip):

it'd probably be good to "focus" a bit on a topic at a time or something?

pnkfelix (May 15 2020 at 14:12, on Zulip):

yes

pnkfelix (May 15 2020 at 14:12, on Zulip):

one might think that the most natural thing would be to go from top to bottom (1 to 5)

pnkfelix (May 15 2020 at 14:12, on Zulip):

but I'm not going to do that

nikomatsakis (May 15 2020 at 14:13, on Zulip):

(ps, for reference, this was my summary of the survey results, but it's fairly similar to what @pnkfelix produced)

pnkfelix (May 15 2020 at 14:13, on Zulip):

I want to talk about 5 first

pnkfelix (May 15 2020 at 14:13, on Zulip):

5. hard to find correct usage patterns; communal knowledge is not shared well

pnkfelix (May 15 2020 at 14:13, on Zulip):

In particular, I saw one result complain about it being hard to find the best practices for using x.py

pnkfelix (May 15 2020 at 14:14, on Zulip):

there are a couple things here

pnkfelix (May 15 2020 at 14:14, on Zulip):

the most immediate one was

pnkfelix (May 15 2020 at 14:14, on Zulip):

I was wondering if maybe I could just put up a hackmd

pnkfelix (May 15 2020 at 14:15, on Zulip):

and everyone could paste in examples of how they invoke x.py

pnkfelix (May 15 2020 at 14:15, on Zulip):

and then I or someone else could post-process those results later

pnkfelix (May 15 2020 at 14:15, on Zulip):

(or maybe we could even dissect it on the fly)

pnkfelix (May 15 2020 at 14:15, on Zulip):

On the fly dissection is probably not the best use of synchronous meeting time

nikomatsakis (May 15 2020 at 14:15, on Zulip):

this fits in I imagine to the work that @WG-rustc-dev-guide has been doing

pnkfelix (May 15 2020 at 14:16, on Zulip):

but I would like to see what people do

nikomatsakis (May 15 2020 at 14:16, on Zulip):

I guess the focus of that has been more like reorganizing the guide, but it's definitely the place that I would imagine covering these sorts of configuration and workflow issues

Santiago Pastorino (May 15 2020 at 14:16, on Zulip):

nikomatsakis said:

this fits in I imagine to the work that @WG-rustc-dev-guide has been doing

:+1:, I think the section of the guide that talks about building is also a bit entangled

nikomatsakis (May 15 2020 at 14:16, on Zulip):

we did at least try to do this once

nikomatsakis (May 15 2020 at 14:16, on Zulip):

but yeah I think it can be improved

pnkfelix (May 15 2020 at 14:16, on Zulip):

https://hackmd.io/9Jns6YrfSk-y4jtKtZpZwg

nikomatsakis (May 15 2020 at 14:16, on Zulip):

though I wonder if part of the problem is folks not knowing about it

nikomatsakis (May 15 2020 at 14:17, on Zulip):

( that said, I honestly just x.py check and x.py build/x.py test with incremental enabled at this point and it seems to.. work ok... =) )

simulacrum (May 15 2020 at 14:17, on Zulip):

yeah, we (me and a few others, not compiler for the most part though) had a design meeting ~1.5? years ago for this at the all hands and that had excellent results but did not end up materializing because "build system is hard")

simulacrum (May 15 2020 at 14:18, on Zulip):

https://paper.dropbox.com/doc/Rustbuild-All-Hands-2019--A0BLGQvhH~_u4wV5vCyDxiyxAg-MLKsxxj1SXORp4Qg8aGbQ

mark-i-m (May 15 2020 at 14:18, on Zulip):

I actually came to lurk about (5) :)

mark-i-m (May 15 2020 at 14:18, on Zulip):

IMHO, part of the problem is that the discussions where people explain things are wasted

mark-i-m (May 15 2020 at 14:19, on Zulip):

I can count at least 3 discussions in recent memory that happened on zulip in various places

nikomatsakis (May 15 2020 at 14:19, on Zulip):

i.e., the knowledge only gets transmitted to the discussion participants?

mark-i-m (May 15 2020 at 14:19, on Zulip):

^^^ yes

nikomatsakis (May 15 2020 at 14:19, on Zulip):

that seems likely

pnkfelix (May 15 2020 at 14:19, on Zulip):

So yeah, we need to back-propagate knowledge to a shared searchable resource

pnkfelix (May 15 2020 at 14:20, on Zulip):

and x.py is just an example of this phenomenon

nikomatsakis (May 15 2020 at 14:20, on Zulip):

I think the work that @simulacrum pointed to seems like a good start on what needs to happen to do more than prop. knowledge; i.e. analyze the workflows people want and try to make them concise

pnkfelix (May 15 2020 at 14:20, on Zulip):

Do we think that discussions from Zulip etc can be back-propagated to rustc-dev-guide?

mark-i-m (May 15 2020 at 14:20, on Zulip):

I'm curious to know what people want to know that isn't in the guide?

mark-i-m (May 15 2020 at 14:20, on Zulip):

Do we think that discussions from Zulip etc can be back-propagated to rustc-dev-guide?

I'm trying to do that a bit

Wesley Wiser (May 15 2020 at 14:20, on Zulip):

I often hear complaints about build times on rust-lang/rust from new contributors. Many of which are doing std work and don't actually need to build a compiler.

mark-i-m (May 15 2020 at 14:21, on Zulip):

e.g. https://github.com/rust-lang/rustc-dev-guide/pull/697

Wesley Wiser (May 15 2020 at 14:21, on Zulip):

So I think a guide that shows different workflows depending on what you're trying to do would be helpful.

nikomatsakis (May 15 2020 at 14:21, on Zulip):

I'm reminded of @boats's post on internals.. which I can't find now

mark-i-m (May 15 2020 at 14:21, on Zulip):

If I happen to observe a useful discussion, I try to open a gh issue, and hopefully we will get to it

pnkfelix (May 15 2020 at 14:21, on Zulip):

Does the rustc-dev-guide support mermaid formatting, by the way?

mark-i-m (May 15 2020 at 14:21, on Zulip):

@pnkfelix not yet, but it's on our radar

pnkfelix (May 15 2020 at 14:22, on Zulip):

I was very impressed by the source code for a flow chart that @nikomatsakis posted recently

varkor (May 15 2020 at 14:22, on Zulip):

nikomatsakis said:

I'm reminded of boats's post on internals.. which I can't find now

https://internals.rust-lang.org/t/experience-report-contributing-to-rust-lang-rust/12012

nikomatsakis (May 15 2020 at 14:22, on Zulip):

I do love mermaid

pnkfelix (May 15 2020 at 14:22, on Zulip):

and was thinking that if it becomes more fun to write diagrams, that can help with making such content

Santiago Pastorino (May 15 2020 at 14:22, on Zulip):

mark-i-m said:

If I happen to observe a useful discussion, I try to open a gh issue, and hopefully we will get to it

yeah we should probably plan a bit on this with @WG-rustc-dev-guide, I think it's a great idea and mainly now that we are planning to spend time going through issues

mark-i-m (May 15 2020 at 14:22, on Zulip):

part of the problem is also that zulip discussions are not supper easy to turn into chapters...

mark-i-m (May 15 2020 at 14:23, on Zulip):

especially as a non-expert

pnkfelix (May 15 2020 at 14:23, on Zulip):

but @nikomatsakis 's point is important

nikomatsakis (May 15 2020 at 14:23, on Zulip):

/me wonders what his point was

pnkfelix (May 15 2020 at 14:23, on Zulip):

it probably isn't ideal to merely capture record collections of workflows

pnkfelix (May 15 2020 at 14:23, on Zulip):

but rather, to also condense them

pnkfelix (May 15 2020 at 14:23, on Zulip):

into their essence, and maybe find ways to improve them

mark-i-m (May 15 2020 at 14:24, on Zulip):

That probably goes beyond the ability of most wg members, including me

pnkfelix (May 15 2020 at 14:24, on Zulip):

Fair

mark-i-m (May 15 2020 at 14:24, on Zulip):

I'm more of a scribe

pnkfelix (May 15 2020 at 14:24, on Zulip):

anyway

pnkfelix (May 15 2020 at 14:24, on Zulip):

What are some take-aways here so far?

mark-i-m (May 15 2020 at 14:25, on Zulip):

From my perspective:

simulacrum (May 15 2020 at 14:25, on Zulip):
simulacrum (May 15 2020 at 14:25, on Zulip):

maybe that's too broad

nikomatsakis (May 15 2020 at 14:25, on Zulip):

heh

pnkfelix (May 15 2020 at 14:25, on Zulip):
  1. At minimum, when knowledge transfer occurs in a "transient" channel like zulip, it would be good if participants could try to make a record (an issue on rustc-dev-guide) about the Question (and the Answer, maybe)?
simulacrum (May 15 2020 at 14:26, on Zulip):

I always come out of discussion about x.py feeling like I didn't explain anything

Santiago Pastorino (May 15 2020 at 14:26, on Zulip):

mark-i-m said:

That probably goes beyond the ability of most wg members, including me

one good thing is that we are a few, so we kind of compensate a bit because there are 3 or 4 that review :)

mark-i-m (May 15 2020 at 14:27, on Zulip):

That's true, but it doesn't really compensate imho

pnkfelix (May 15 2020 at 14:27, on Zulip):

if my suggestion above leads to an explosion of issues on rustc-dev-guide, then we can revisit that later?

nikomatsakis (May 15 2020 at 14:27, on Zulip):

it's certainly true that the "how to build and run" section in rustc-dev-guide is long

mark-i-m (May 15 2020 at 14:27, on Zulip):

if my suggestion above leads to an explosion of issues on rustc-dev-guide, then we can revisit that later?

I would welcome that

nikomatsakis (May 15 2020 at 14:27, on Zulip):

or, perhaps, could be "sharpened" onto "what are you trying to do" a bit more?

pnkfelix (May 15 2020 at 14:27, on Zulip):

as in, you would welcome an explosion, @mark-i-m ?

Santiago Pastorino (May 15 2020 at 14:27, on Zulip):

mark-i-m said:

That's true, but it doesn't really compensate imho

no, I'm just saying that is a bit better than just having one non expert doing that alone :)

mark-i-m (May 15 2020 at 14:28, on Zulip):

pnkfelix said:

as in, you would welcome an explosion, mark-i-m ?

yes, because it means we at least have _something_ to point people to

simulacrum (May 15 2020 at 14:28, on Zulip):

basically - if we focus on x.py I think the problem I've had with writing docs is that I have no good way to identify "key pain points"

mark-i-m (May 15 2020 at 14:28, on Zulip):

nikomatsakis said:

it's certainly true that the "how to build and run" section in rustc-dev-guide is long

Santiago and I were actually just discussing this on Tuesday

simulacrum (May 15 2020 at 14:28, on Zulip):

(and I think this is more broadly true too)

Santiago Pastorino (May 15 2020 at 14:28, on Zulip):

nikomatsakis said:

it's certainly true that the "how to build and run" section in rustc-dev-guide is long

one of the things we've talked with @mark-i-m is splitting in two parts, one at the beginning that is what you need to get everything up and running and another one that is a bit more on the inners of the build system

nikomatsakis (May 15 2020 at 14:28, on Zulip):

would it be worth trying to gather a bit more data?

nikomatsakis (May 15 2020 at 14:29, on Zulip):

like, maybe host a survey for "new compiler contributors"

nikomatsakis (May 15 2020 at 14:29, on Zulip):

and encourage folks who either are newly working on the compiler,

nikomatsakis (May 15 2020 at 14:29, on Zulip):

or who came and bounced,

nikomatsakis (May 15 2020 at 14:29, on Zulip):

to talk about why?

simulacrum (May 15 2020 at 14:29, on Zulip):

I think that'd be interesting

nikomatsakis (May 15 2020 at 14:29, on Zulip):

a short one, presumably, that we would try to seed with information

nikomatsakis (May 15 2020 at 14:29, on Zulip):

about our hypotheses

nikomatsakis (May 15 2020 at 14:29, on Zulip):

(we should probably broaden it somewhat to capture folks trying to extend the stdlib too)

pnkfelix (May 15 2020 at 14:30, on Zulip):

Okay so I would like to try to summarize the take-aways and action items from discussion so far

pnkfelix (May 15 2020 at 14:30, on Zulip):

and post it in the hackmd

mark-i-m (May 15 2020 at 14:30, on Zulip):

basically - if we focus on x.py I think the problem I've had with writing docs is that I have no good way to identify "key pain points"

Perhaps we can start another thread to discuss this? I have some ideas

Wesley Wiser (May 15 2020 at 14:31, on Zulip):

Semi-related: setting up config.toml is not always obvious to new contributors. Tweaking llvm target support is helpful for people without beefy computers and the default is to just build everything. Usually just building support for x86 is sufficient.

Wesley Wiser (May 15 2020 at 14:31, on Zulip):

Setting debug-assertions = 1 is also very helpful and not done by default (I think)

simulacrum (May 15 2020 at 14:31, on Zulip):

Wesley Wiser said:

Semi-related: setting up config.toml is not always obvious to new contributors. Tweaking llvm target support is helpful for people without beefy computers and the default is to just build everything. Usually just building support for x86 is sufficient.

But also then you (likely) get test errors, too :/

Yeah these are good things to hear though...

pnkfelix (May 15 2020 at 14:32, on Zulip):

Wesley Wiser said:

Setting debug-assertions = 1 is also very helpful and not done by default (I think)

I want to double check if it is implied by debug = 1

simulacrum (May 15 2020 at 14:32, on Zulip):

it is, I think

pnkfelix (May 15 2020 at 14:32, on Zulip):

some discussion elsewhere led me to wonder that it might not be so

simulacrum (May 15 2020 at 14:32, on Zulip):

but you also want debug-assertions-std = false most likely

pnkfelix (May 15 2020 at 14:32, on Zulip):

because the latter is slow?

mark-i-m (May 15 2020 at 14:32, on Zulip):

I think config.toml is easy to forget because you can run x.py without it

pnkfelix (May 15 2020 at 14:32, on Zulip):

oh no we are definitely getting back into the weeds which was not what I wanted

simulacrum (May 15 2020 at 14:32, on Zulip):

heh

Wesley Wiser (May 15 2020 at 14:32, on Zulip):

Sorry!

pnkfelix (May 15 2020 at 14:32, on Zulip):

it was my fault!

pnkfelix (May 15 2020 at 14:32, on Zulip):

anwya

simulacrum (May 15 2020 at 14:32, on Zulip):

debug asserts on full is 2x slower, just compiler is 1.5x slower

mark-i-m (May 15 2020 at 14:33, on Zulip):

that was on the list :P

pnkfelix (May 15 2020 at 14:33, on Zulip):

Meeting Take-aways and Action Items

hard to find correct usage patterns; communal knowledge is not shared well

pnkfelix (May 15 2020 at 14:33, on Zulip):

is anyone volunteering to spearhead the gathering of more data?

simulacrum (May 15 2020 at 14:33, on Zulip):

I would also maybe add -- we should talk to people who are currently contributing

simulacrum (May 15 2020 at 14:33, on Zulip):

e.g. send me your x.py pain points or something

pnkfelix (May 15 2020 at 14:33, on Zulip):

true

simulacrum (May 15 2020 at 14:34, on Zulip):

like, focusing just on newcomers isn't necessarily best

pnkfelix (May 15 2020 at 14:34, on Zulip):

sure

simulacrum (May 15 2020 at 14:34, on Zulip):

(indeed I would almost prioritize existing people because they can then mentor more effectively in theory)

Santiago Pastorino (May 15 2020 at 14:34, on Zulip):

we can start by gathering some data opening a thread on zulip, so contributors can comment here and from there we could launch a larger kind of survey

pnkfelix (May 15 2020 at 14:34, on Zulip):

the survey probably won't be focused just on x.py, though

varkor (May 15 2020 at 14:34, on Zulip):

mark-i-m said:

I think config.toml is easy to forget because you can run x.py without it

this is probably also tangential, but it could be worth considering a prompt the first time x.py is run, which walks a new contributor through setting up config.toml without having to wade through all the uncommon options — just some simple questions for a "quick start"

pnkfelix (May 15 2020 at 14:34, on Zulip):

or maybe it will be

pnkfelix (May 15 2020 at 14:34, on Zulip):

heh

pnkfelix (May 15 2020 at 14:34, on Zulip):

anyway

varkor (May 15 2020 at 14:34, on Zulip):

e.g. "do you want to build the entire compiler, or just the standard library"

pnkfelix (May 15 2020 at 14:35, on Zulip):

are there any other take-aways action items people want to add?

pnkfelix (May 15 2020 at 14:35, on Zulip):

(i'll try to fix up the summary for the two so far)

simulacrum (May 15 2020 at 14:35, on Zulip):

I still feel a bit "out there" like we haven't solved anything :)

but I don't have concrete thoughts

mark-i-m (May 15 2020 at 14:36, on Zulip):

I created https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/x.2Epy.20concerns/near/197700338 to discuss x.py more

nikomatsakis (May 15 2020 at 14:36, on Zulip):

I like this suggestion from @varkor a lot

pnkfelix (May 15 2020 at 14:36, on Zulip):

@simulacrum well just getting people aware of the problem is important...

nikomatsakis (May 15 2020 at 14:36, on Zulip):

it always annoys me that the setup from a "Fresh clone" is geared towards building for production use

nikomatsakis (May 15 2020 at 14:36, on Zulip):

and not development

nikomatsakis (May 15 2020 at 14:36, on Zulip):

it seems sort of like the opposite of what most folks want

pnkfelix (May 15 2020 at 14:37, on Zulip):

this has indeed been a long-standing tension

simulacrum (May 15 2020 at 14:37, on Zulip):

yes, it's an interesting point

pnkfelix (May 15 2020 at 14:37, on Zulip):

we had talked, back when we first decided to turn optimize on by default

pnkfelix (May 15 2020 at 14:37, on Zulip):

of having the script prompt you

pnkfelix (May 15 2020 at 14:37, on Zulip):

to say "hey you haven't actually indicated what kind of development you're doing"

simulacrum (May 15 2020 at 14:37, on Zulip):

I think this might be a good intro to some other topics -- e.g. right now there's not clear ownership of this piece

simulacrum (May 15 2020 at 14:37, on Zulip):

So I feel mildly uncomfortable just submitting PRs changing defaults like that

pnkfelix (May 15 2020 at 14:37, on Zulip):

(at least, I have vague memories of the idea being put forward then)

pnkfelix (May 15 2020 at 14:38, on Zulip):

((but unfortunately we didn't follow-through... assuming my memories here are anything close to accurate))

pnkfelix (May 15 2020 at 14:38, on Zulip):

simulacrum said:

So I feel mildly uncomfortable just submitting PRs changing defaults like that

well I imagine this sort of thing could be an MCP

pnkfelix (May 15 2020 at 14:38, on Zulip):

but yes, @simulacrum is right, lets shift gears

pnkfelix (May 15 2020 at 14:39, on Zulip):

none of the high-level bullet points explicitly said "lack of ownership", but it was a theme from some survey results

pnkfelix (May 15 2020 at 14:39, on Zulip):

and I think it falls under:

pnkfelix (May 15 2020 at 14:39, on Zulip):

3. lack of focus: triage meeting goes into weeds; our chat is forked; our team is too broad

pnkfelix (May 15 2020 at 14:39, on Zulip):

so lets just expand that to

pnkfelix (May 15 2020 at 14:40, on Zulip):

3. lack of focus: triage meeting goes into weeds; our chat is forked; our team is too broad; ownership is unclear

pnkfelix (May 15 2020 at 14:40, on Zulip):

so we do have expert maps

pnkfelix (May 15 2020 at 14:41, on Zulip):

which are incomplete. I assume what's on them is relatively accurate, since they were created semi recently...?

nikomatsakis (May 15 2020 at 14:41, on Zulip):

well, revising the way we handle "areas" of the compiler is kind of the subject of this meeting proposal

pnkfelix (May 15 2020 at 14:41, on Zulip):

but I think we've also shied away from explicit ownership of code

pnkfelix (May 15 2020 at 14:41, on Zulip):

that's true

nikomatsakis (May 15 2020 at 14:41, on Zulip):

in part because the expert map I don't think has been that effective (nor esp. discoverable)

simulacrum (May 15 2020 at 14:42, on Zulip):

I never remember it

pnkfelix (May 15 2020 at 14:42, on Zulip):

So compiler-team#288 is an example of a way we are attempting to address the ownership issue

nikomatsakis (May 15 2020 at 14:42, on Zulip):

I don't think it's so much about ownership of the code, although I think that's maybe sometimes a useful concept

pnkfelix (May 15 2020 at 14:42, on Zulip):

owner is wrong word

pnkfelix (May 15 2020 at 14:42, on Zulip):

steward is perhaps better

pnkfelix (May 15 2020 at 14:42, on Zulip):

i.e. people who are knowledgable and try to steer that particular boat

pnkfelix (May 15 2020 at 14:43, on Zulip):

on this fleet of ships we call rustc

pnkfelix (May 15 2020 at 14:43, on Zulip):

This whole bullet is of course very broad

Santiago Pastorino (May 15 2020 at 14:43, on Zulip):

nikomatsakis said:

in part because the expert map I don't think has been that effective (nor esp. discoverable)

if we can go ahead at some point with the areas idea, we may also be able to display areas, leads, maintainers of each area on the website for discoverability, among other things we can of course do :)

nikomatsakis (May 15 2020 at 14:43, on Zulip):

it seems like the problem with things like x.py -- and perhaps some other aspects of the compiler like the way it invokes the linker, or details of things like particular targets -- is that there kind of is no owner or anybody who really cares for it that closely

simulacrum (May 15 2020 at 14:44, on Zulip):

Yes -- e.g. for x.py in some sense I feel it's "mine" but it affects literally everybody which makes changes to it super scary

nikomatsakis (May 15 2020 at 14:44, on Zulip):

bootstrapping that expertise was a motivation for the windows target group idea that's been kicking around, since it seems like that's a particular case that comes up semi-frequently (e.g., what symbols to export, what version of gnu toolchain to support, etc etc)

pnkfelix (May 15 2020 at 14:45, on Zulip):

simulacrum said:

Yes -- e.g. for x.py in some sense I feel it's "mine" but it affects literally everybody which makes changes to it super scary

That's interesting. I'm more scared of changes to CI stuff

Santiago Pastorino (May 15 2020 at 14:45, on Zulip):

simulacrum said:

Yes -- e.g. for x.py in some sense I feel it's "mine" but it affects literally everybody which makes changes to it super scary

shouldn't we apply MCP there and let you do it in a more relaxed fashion? :)

pnkfelix (May 15 2020 at 14:45, on Zulip):

i.e. yes, x.py things can break the world, but also, since everyone is using it, problems will get discovered (and either fixed or backed out) quickly

pnkfelix (May 15 2020 at 14:45, on Zulip):

but for CI stuff, I cannot test it locally for the most part

simulacrum (May 15 2020 at 14:46, on Zulip):

well x.py is also CI

pnkfelix (May 15 2020 at 14:46, on Zulip):

at least, not with confidence

simulacrum (May 15 2020 at 14:46, on Zulip):

so if you edit it and... stop running tests on accident, well, woops

pnkfelix (May 15 2020 at 14:46, on Zulip):

ah okay, that kind of bug is interesting

pnkfelix (May 15 2020 at 14:46, on Zulip):

in principle we could smoke test for such things

simulacrum (May 15 2020 at 14:46, on Zulip):

e.g. with some of the workflows if CI "misconfigures" into "just std" mode

simulacrum (May 15 2020 at 14:46, on Zulip):

anyway, maybe that's too into the weeds

pnkfelix (May 15 2020 at 14:46, on Zulip):

its an interesting problem

Wesley Wiser (May 15 2020 at 14:47, on Zulip):

It feels to me like in some ways we're kind of talking a bit about the "Lack of leadership bandwidth" issue because it's not clear who the right person to consult with is for various kinds of changes. That makes it difficult to know if the change is good or not.

simulacrum (May 15 2020 at 14:47, on Zulip):

I would agree there, for sure

pnkfelix (May 15 2020 at 14:47, on Zulip):

so what about @Santiago Pastorino suggestion of letting MCP handle that?

nikomatsakis (May 15 2020 at 14:47, on Zulip):

the last time we talked about this I think was in the context of the "working group retro"

pnkfelix (May 15 2020 at 14:47, on Zulip):

MCP is lighter weight than full rfcbot approval system

simulacrum (May 15 2020 at 14:48, on Zulip):

MCP is an interesting idea

nikomatsakis (May 15 2020 at 14:48, on Zulip):

at the time, we talked about a few concrete changes, but one of them (which never happened) was doing some active work with each initiative to form a kind of "roadmap and plan"

simulacrum (May 15 2020 at 14:48, on Zulip):

I hadn't thought of using it for e.g. x.py

nikomatsakis (May 15 2020 at 14:48, on Zulip):

to me this ties in a lot with next week's design meeting, i.e., we have to first identify a clear and semi-minimal set of priorities

nikomatsakis (May 15 2020 at 14:48, on Zulip):

to make that feasible

nikomatsakis (May 15 2020 at 14:48, on Zulip):

I guess this doesn't address the problem around x.py :)

pnkfelix (May 15 2020 at 14:48, on Zulip):

yeah

Santiago Pastorino (May 15 2020 at 14:49, on Zulip):

maybe MCP sounds like changes should be large in the amount of code used to solve problems but should also a apply to kind of huge changes in the way you interact with the compiler or in particular the commands you run everyday like ./x.py

nikomatsakis (May 15 2020 at 14:49, on Zulip):

I'm just thinking about 'leadership bandwidth'

pnkfelix (May 15 2020 at 14:49, on Zulip):

well I have perhaps a different take on this topic

pnkfelix (May 15 2020 at 14:49, on Zulip):

re lack of focus

nikomatsakis (May 15 2020 at 14:49, on Zulip):

I would definitely use MCP for x.py in any case :)

pnkfelix (May 15 2020 at 14:49, on Zulip):

and the team being too broad

pnkfelix (May 15 2020 at 14:49, on Zulip):

do we need to break up the team into smaller subteams?

nikomatsakis (May 15 2020 at 14:49, on Zulip):

this was the goal of the longer term goal of the area proposal

nikomatsakis (May 15 2020 at 14:49, on Zulip):

not necessarily teams , but to have some kind of active leadership around the areas of the code

nikomatsakis (May 15 2020 at 14:50, on Zulip):

and encourage folks to think about things in those terms

pnkfelix (May 15 2020 at 14:50, on Zulip):

okay so I guess we can just let that wait for that meeting then

pnkfelix (May 15 2020 at 14:50, on Zulip):

I just want to try to relay the idea

pnkfelix (May 15 2020 at 14:50, on Zulip):

that we do want to address those issues

pnkfelix (May 15 2020 at 14:51, on Zulip):

So, take-aways here are ...

pnkfelix (May 15 2020 at 14:51, on Zulip):
  1. We hope the future Areas of Compiler steering meeting will help address the lack of focus that stems from team over-reach
nikomatsakis (May 15 2020 at 14:52, on Zulip):

(see also MCP compiler-team#293 that I just filed :)

Santiago Pastorino (May 15 2020 at 14:52, on Zulip):

nikomatsakis said:

I would definitely use MCP for x.py in any case :)

in particular about this, given that we are talking about ./x.py and config.toml so much :), why don't we (maybe @simulacrum and @WG-rustc-dev-guide) try to come up with an MCP with a set of cool and useful changes to make things a bit more clear?

pnkfelix (May 15 2020 at 14:52, on Zulip):
  1. encourage people to use MCP process rather than having one individual stress over e..g whether a delta to x.py is safe
pnkfelix (May 15 2020 at 14:53, on Zulip):

by the way

pnkfelix (May 15 2020 at 14:53, on Zulip):

if a PR already exists

pnkfelix (May 15 2020 at 14:53, on Zulip):

you don't have to jump to MCP, arguably

pnkfelix (May 15 2020 at 14:53, on Zulip):

that is, you could I-nominate it, right?

pnkfelix (May 15 2020 at 14:54, on Zulip):

which allows for even lighter-weight discussion in short term, and let people there decide if MCP is warranted?

nikomatsakis (May 15 2020 at 14:54, on Zulip):

in principle

nikomatsakis (May 15 2020 at 14:54, on Zulip):

I was thinking that I think MCP is more about "high-level idea" than "review the impl"

pnkfelix (May 15 2020 at 14:55, on Zulip):

I think we've been doing a really good job lately, thanks in no small part to wg-prioritization, of actually to and through all the I-nominations each week

nikomatsakis (May 15 2020 at 14:55, on Zulip):

so it may not apply to giving confidence that x.py changes won't skip tests

pnkfelix (May 15 2020 at 14:55, on Zulip):

we've had this happen in the past

simulacrum (May 15 2020 at 14:55, on Zulip):

mcp would certainly help I think

pnkfelix (May 15 2020 at 14:55, on Zulip):

where portions of test suite have been skipped unexpected. Not necessarily due to x.py

simulacrum (May 15 2020 at 14:55, on Zulip):

(more broadly even than ex.py)

pnkfelix (May 15 2020 at 14:56, on Zulip):

but rather compiletest bugs/mistakes

pnkfelix (May 15 2020 at 14:56, on Zulip):

I'm still idly wondering if we can/should think about ways to attack that

pnkfelix (May 15 2020 at 14:56, on Zulip):

you know, a "who tests the tester and/or tests?" kind of thing

pnkfelix (May 15 2020 at 14:56, on Zulip):

anyway

pnkfelix (May 15 2020 at 14:57, on Zulip):

meeting time is almost up. :sad:

Wesley Wiser (May 15 2020 at 14:57, on Zulip):

I think there's a lot of good content from the survey data. Obviously we're not going to get to all of it in this meeting. Do we have a plan for what to do with it going forward? We've already booked Friday meetings the rest of the month. I think it would be a shame though not to go through more of the content.

pnkfelix (May 15 2020 at 14:57, on Zulip):

there were three bullets left

pnkfelix (May 15 2020 at 14:57, on Zulip):
  1. long standing problems going unaddressed (or hard to track progress thereof; lack of status updates)
  2. worker drain and lack of bandwidth.
  3. [lack of focus; already discussed]
  4. change-to-test cycle is too long (more broadly, everything is too high latency)
nikomatsakis (May 15 2020 at 14:58, on Zulip):

Wesley Wiser said:

I think there's a lot of good content from the survey data. Obviously we're not going to get to all of it in this meeting. Do we have a plan for what to do with it going forward? We've already booked Friday meetings the rest of the month. I think it would be a shame though not to go through more of the content.

maybe a good idea would be to look it over and file follow-up meeting proposals?

nikomatsakis (May 15 2020 at 14:58, on Zulip):

on specific bullets?

nikomatsakis (May 15 2020 at 14:58, on Zulip):

not sure @Wesley Wiser if anything in particular caught your eye

pnkfelix (May 15 2020 at 14:58, on Zulip):

I think that's a great idea, maybe even asynchronously brainstorm ahead of time

Wesley Wiser (May 15 2020 at 14:58, on Zulip):

Well most of it unfortunately

pnkfelix (May 15 2020 at 14:58, on Zulip):

so that the proposal wouldn't necessarily just be "here's a problem I care about"

pnkfelix (May 15 2020 at 14:59, on Zulip):

but rather, "here's a problem I care about, and we should brain storm solutions on the linked zulip thread for this meeting proposal"

pnkfelix (May 15 2020 at 14:59, on Zulip):

(I in particular care about the change-to-test cycle.)

nikomatsakis (May 15 2020 at 14:59, on Zulip):

I'm particularly interested in thinking more about sharpening our focus and increasing the visibility into our status, both internally and externally

pnkfelix (May 15 2020 at 15:00, on Zulip):

oh true, we should have discussed that aspect of things more

nikomatsakis (May 15 2020 at 15:00, on Zulip):

But also on the ways to improve the "contributor experience", i.e., I think the only solution around bandwidth ultimately is to be attracting and retaining skilled folks

nikomatsakis (May 15 2020 at 15:01, on Zulip):

probably getting more companies hiring or giving people time to contribute is also a big help;

pnkfelix (May 15 2020 at 15:01, on Zulip):

okay, well, there were not a huge number of action items here

Wesley Wiser (May 15 2020 at 15:01, on Zulip):

I think if I had to pick top three not already discussed it would be:

nikomatsakis (May 15 2020 at 15:01, on Zulip):

I've heard tell of some kind of informal league of googlers putting in their 20% time to help out with rustc for example

pnkfelix (May 15 2020 at 15:03, on Zulip):

anyway, we're over the hour now.

pnkfelix (May 15 2020 at 15:03, on Zulip):

the big items are

pnkfelix (May 15 2020 at 15:03, on Zulip):
  1. we will have some follow-up meetings, based on what proposals get filed
pnkfelix (May 15 2020 at 15:04, on Zulip):
  1. it would be good to have a survey of new, current and ... "bounced" compiler contributors
pnkfelix (May 15 2020 at 15:04, on Zulip):

I think that's all

nikomatsakis (May 15 2020 at 15:04, on Zulip):

pnkfelix said:

  1. it would be good to have a survey of new, current and ... "bounced" compiler contributors

does somebody want to try and organize that?

pnkfelix (May 15 2020 at 15:05, on Zulip):

maybe wg-rustc-dev-guide ?

pnkfelix (May 15 2020 at 15:05, on Zulip):

it seems like it falls under their purview. well, depending on what we do

pnkfelix (May 15 2020 at 15:05, on Zulip):

I guess if all we do is add content to rustc-dev-guide, then its under their purview

pnkfelix (May 15 2020 at 15:05, on Zulip):

but if we actually make internal changes

pnkfelix (May 15 2020 at 15:06, on Zulip):

e..g make x.py prompt for what mode it should run in when its run the first time

pnkfelix (May 15 2020 at 15:06, on Zulip):

then that's not a rustc-dev-guide things. Its more of a "wg-newcomer-experience" ...

nikomatsakis (May 15 2020 at 15:06, on Zulip):

I'm happy to help a bit, it may also interest @XAMPPRocky

nikomatsakis (May 15 2020 at 15:06, on Zulip):

I can't do much :)

nikomatsakis (May 15 2020 at 15:08, on Zulip):

(btw, I like the new dedicated zulip stream, makes it easier to follow the meeting)

mark-i-m (May 15 2020 at 15:08, on Zulip):

I guess if all we do is add content to rustc-dev-guide, then its under their purview

Not sure how exactly to conduct a survey, but we might be able to do it. Guidance from others might be helpful

nikomatsakis (May 15 2020 at 15:10, on Zulip):

opened #t-compiler > contributor survey

pnkfelix (May 15 2020 at 15:10, on Zulip):

anyway, we are way over the hour. Thanks to everyone in @T-compiler/meeting for attending!

Last update: Nov 25 2020 at 02:30UTC