Stream: t-compiler

Topic: design meeting 2019-09-20


nikomatsakis (Sep 20 2019 at 13:43, on Zulip):

Dear @T-compiler/meeting: Design meeting today in 20 minutes.

Topic: Target tier policy, compiler-team#166

Feel free to pre-read @Josh Triplett's proposal =)

nikomatsakis (Sep 20 2019 at 13:44, on Zulip):

Also: looking for volunteers to do a summary after the fact.

Example: https://github.com/rust-lang/compiler-team/pull/173 (which summarized our last design meeting)

Josh Triplett (Sep 20 2019 at 13:48, on Zulip):

I'm here and ready.

nikomatsakis (Sep 20 2019 at 13:57, on Zulip):

BTW, @Alex Crichton, are you able to attend this meeting about target tierse? I, uh, meant to ask you earlier, but I don't think I did.

Pietro Albini (Sep 20 2019 at 14:01, on Zulip):

o/

nikomatsakis (Sep 20 2019 at 14:01, on Zulip):

OK @T-compiler/meeting -- design meeting is now. I'll give till 10:03 for people to show up

nikomatsakis (Sep 20 2019 at 14:01, on Zulip):

Announcements

nikomatsakis (Sep 20 2019 at 14:04, on Zulip):

OK, shall we get started?

nikomatsakis (Sep 20 2019 at 14:04, on Zulip):

I guess not a lot of announcements since yesterday :)

Alex Crichton (Sep 20 2019 at 14:04, on Zulip):

:wave:

nikomatsakis (Sep 20 2019 at 14:04, on Zulip):

I'll just add one: next week is the planning meeting

nikomatsakis (Sep 20 2019 at 14:04, on Zulip):

@Josh Triplett, care to start?

Josh Triplett (Sep 20 2019 at 14:06, on Zulip):

So: I've gotten various review requests for adding new targets (at tier 3), other people have as well, and everyone has thus far just evaluated them independently and assumed sufficient authority to accept them, while often observing the lack of a policy anywhere to support them.

Josh Triplett (Sep 20 2019 at 14:06, on Zulip):

I've also had discussions with people about what it takes to move targets up to a higher tier.

nikomatsakis (Sep 20 2019 at 14:06, on Zulip):

I'd like to add that I feel like (a) I often don't know what tier something is and (b) it's very confusing to me how to prioritize bugs that are not in "mainstream" platforms

Josh Triplett (Sep 20 2019 at 14:06, on Zulip):

And for that, the answer has always firmly been "I don't know", with perhaps a dash of "maybe ask the core team or something".

nikomatsakis (Sep 20 2019 at 14:06, on Zulip):

(from POV of "compiler team dev")

Josh Triplett (Sep 20 2019 at 14:08, on Zulip):

I also feel that tier policy is something that needs to very carefully consider the failure modes that it can fall into.

Josh Triplett (Sep 20 2019 at 14:09, on Zulip):

Thinking about it from a perspective of how we prioritize things: when we make a target tier 2, or tier 1, as far as I can tell we currently assume that this means anyone who breaks the build or tests has the sole responsibility to fix it. Even if for a platform they don't understand or have access to.

pnkfelix (Sep 20 2019 at 14:09, on Zulip):

wait is that right? Do we do CI for all of our tier 2 targets?

Pietro Albini (Sep 20 2019 at 14:09, on Zulip):

we do cross-compiling for all tier 2 targerts

nikomatsakis (Sep 20 2019 at 14:09, on Zulip):

Can we just review briefly what tier 1/2/3 mean?

Josh Triplett (Sep 20 2019 at 14:10, on Zulip):

Let's, yes.

Pietro Albini (Sep 20 2019 at 14:10, on Zulip):

(then some tier 2 target also run their tests inside qemu today)

nikomatsakis (Sep 20 2019 at 14:10, on Zulip):

I think it is:

- Tier 1 -- fully supported. We run tests and fix bugs.
- Tier 2 -- we run builds, but do not run tests; I am not clear on how much we support this
- Tier 3 -- we let you land code but do not block on it building

Josh Triplett (Sep 20 2019 at 14:10, on Zulip):

Right now: tier 3 means "this target exists in the source and people can build it if they want". There are some tier 3 targets for which we also build binaries for rustup. Then tier 2 means we guarantee builds but not tests passing, and tier 1 means we guarantee builds and tests.

nikomatsakis (Sep 20 2019 at 14:11, on Zulip):

do we distribute all tier 2 targets with rustup?

Alex Crichton (Sep 20 2019 at 14:11, on Zulip):

to add to that, in practice "tier 2" we actually test some one CI, so we effectively put the burden on PR authors to fix tests. For "tier 3" there's also a strong sentiment that you should fix platforms in your PR if it's small, so it's effectively that we do frequently block on building it (asking users to build it locally)

Josh Triplett (Sep 20 2019 at 14:11, on Zulip):

https://forge.rust-lang.org/release/platform-support.html

Alex Crichton (Sep 20 2019 at 14:11, on Zulip):

tbh the tier distinction I think is pretty fuzzy today and there's probably more exceptions to the rules than there are rules

Pietro Albini (Sep 20 2019 at 14:12, on Zulip):

do we distribute all tier 2 targets with rustup?

mostly, there is a "tier 2.5" that's not shipped but built

Alex Crichton (Sep 20 2019 at 14:12, on Zulip):

it may be best to go over @Josh Triplett's proposal for new tiers though?

nikomatsakis (Sep 20 2019 at 14:12, on Zulip):

@Alex Crichton are you saying we test some Tier 2 targets on CI? (but not all)

Alex Crichton (Sep 20 2019 at 14:12, on Zulip):

@nikomatsakis correct yeah, for example wasm/arm/aarch64 are all "tier 2" but we test them on CI (same w/ emscripten)

Josh Triplett (Sep 20 2019 at 14:12, on Zulip):

One other interesting distinction...

Alex Crichton (Sep 20 2019 at 14:12, on Zulip):

that's where the current tier distinction is probably too fuzzy to talk about since it's just so fuzzy with so many exceptions

pnkfelix (Sep 20 2019 at 14:13, on Zulip):

For tier 2, we don't test builds of rustc itself (e.g. for raspberry Pi), right? I think that has been a reason we see some bugs arise that compiler team is not prepared to address

Josh Triplett (Sep 20 2019 at 14:13, on Zulip):

Some targets are things that we actually build hosted toolchains for (such as a binary of rustc and cargo running on ARM Linux), but most targets we just cross-compile std and core.

Alex Crichton (Sep 20 2019 at 14:13, on Zulip):

@pnkfelix correct we only actually run compilers on x86/x86_64 platforms

Alex Crichton (Sep 20 2019 at 14:13, on Zulip):

(note that whether or not we build rustc/cargo for a target also frequently evolves over time to add more wrenches)

nikomatsakis (Sep 20 2019 at 14:14, on Zulip):

OK. So I agree it's probably not worth getting too far into the weeds of what we do today, but I do think it's worth trying to highlight all the "columns" -- i.e., the traditional tier description leaves out lots of important details (which may even indicate we want more tiers...)

Josh Triplett (Sep 20 2019 at 14:14, on Zulip):

For today, I don't think we need to cover "which platforms do we build rustc and cargo for". That's less a support policy than it is a "which platforms do people need" policy.

Josh Triplett (Sep 20 2019 at 14:15, on Zulip):

What I do want to cover is the tier policy proposal. I wrote it up largely as a straw proposal, to garner feedback, but I think I covered most of what we're likely to care about for adding new tiers.

nikomatsakis (Sep 20 2019 at 14:15, on Zulip):

To me, though the high order bit is what level of support we are expected to provide when things go wrong. I think then it is kind of:

- Tier 3 -- none at all.
- Tier 2 -- Rust org will notify you, but there should be some dedicated folks who will fix independently (sort of like tools)
- Tier 1 -- we block PRs (and maybe WASM is just misclassified, for example) ?

nikomatsakis (Sep 20 2019 at 14:15, on Zulip):

yep, sounds good, sorry

Josh Triplett (Sep 20 2019 at 14:16, on Zulip):

That's an interesting point, actually.

Pietro Albini (Sep 20 2019 at 14:16, on Zulip):

(we block PRs on some arm virtualized testing too)

Josh Triplett (Sep 20 2019 at 14:16, on Zulip):

There are some "tier 2" platforms for which we should run tests.

Josh Triplett (Sep 20 2019 at 14:17, on Zulip):

But also, I would argue that for both tier 2 and tier 1, we do need dedicated folks "on call" who care about a target, unless we specifically say that it's a target for which we can expect everyone to pitch in with no special expertise needed.

Josh Triplett (Sep 20 2019 at 14:18, on Zulip):

Today, at least, we do block PRs on tier 2 building and tier 1 passing tests.

Josh Triplett (Sep 20 2019 at 14:18, on Zulip):

(And on some tier 2 passing tests.)

Josh Triplett (Sep 20 2019 at 14:18, on Zulip):

I agree with @nikomatsakis's observation that in practice we do treat WASM targets as tier 1.

Josh Triplett (Sep 20 2019 at 14:18, on Zulip):

(And we ought to put out a press release to that effect. ;) )

nikomatsakis (Sep 20 2019 at 14:19, on Zulip):

I definitely like the idea of "dedicated folks"

Josh Triplett (Sep 20 2019 at 14:19, on Zulip):

I think the tier 2 / tier 1 distinction still makes sense: guaranteed build versus guaranteed tests pass.

Tshepang Lekhonkhobe (Sep 20 2019 at 14:19, on Zulip):

should we use a different terms than "tier X", and instead maintain a table, with instructions on what to do in order for a platform to get a check mark

nikomatsakis (Sep 20 2019 at 14:19, on Zulip):

I've also thought about having "instructions for debugging problems" -- i.e., I'd like to know how to run qemu etc

Josh Triplett (Sep 20 2019 at 14:20, on Zulip):

@nikomatsakis Yeah, that's a good idea.

Josh Triplett (Sep 20 2019 at 14:20, on Zulip):

In the proposal I had this: "should use any such issue as an opportunity to educate the Rust community about portability to their target."

nikomatsakis (Sep 20 2019 at 14:21, on Zulip):

should we use a different term than "tier X", and instead maintain a table, with instructions on what to do in order for a platform to get a check mark

(I was wondering the same, and it's probably a good idea, but I do think it's still useful to have broad categories -- i.e., to be tier 1, you need all these boxes checked -- in any case I think we can defer this detail slightly)

Josh Triplett (Sep 20 2019 at 14:21, on Zulip):

But I'm going to add a bullet point saying "If possible, instructions for the Rust community for how to build and run tests for the platform, ideally using emulation."

nikomatsakis (Sep 20 2019 at 14:21, on Zulip):

I guess I would say that, absent such instructions, they should not expect any assistance -- and we should not block on tests :)

Josh Triplett (Sep 20 2019 at 14:22, on Zulip):

Yeah, you have to have such instructions for tier 1 (though they're allowed to be "you need xyz hardware"), and you should have such instructions for tier 2 or if not you're expected to be pageable at 3am. :)

Josh Triplett (Sep 20 2019 at 14:24, on Zulip):

Any thoughts on the proposal requirements as written? Would it be helpful for me to go over the tiers one by one?

pnkfelix (Sep 20 2019 at 14:25, on Zulip):

When it comes to this idea of "dedicated folks" to contact for Tier 2 issues, that the set of such folks needs to be larger than 1 person for support to be viable? and if this is right, do we have any idea where the threshold lies?

Alex Crichton (Sep 20 2019 at 14:25, on Zulip):

One thing I think is pretty important to consider here as well is that we've got a relatively good track record of figuring out what tiers are. Although it slightly changes over time we generally all seem to always have agreement there's three tiers and a vague sense of commonality amongst the requirements. What I don't think we have a great process for is movement between tiers and addition to tiers. For example wasm didn't exactly go through a formal process to get tested on CI (nor did really anything else). I think it's definitely important to flesh out the process a bit in terms of how things get added to tiers, where/when they get moved, etc.

Alex Crichton (Sep 20 2019 at 14:25, on Zulip):

@Josh Triplett's proposal highlights much of this already, just wanted to highlight the highlight

Pietro Albini (Sep 20 2019 at 14:26, on Zulip):

if not you're expected to be pageable at 3am. :)

regarding that, a thing I haven't seen addressed in the proposal is what happens when some requirements are not meet anymore, do we downgrade tiers? is that a breaking change (I think so)?

nikomatsakis (Sep 20 2019 at 14:26, on Zulip):

I think it's definitely important to flesh out the process a bit in terms of how things get added to tiers, where/when they get moved, etc.

yes, I wanted to emphasize this -- and also that the doc doesn't mention the release or infra teams, but it seems like they have a role in this too

Josh Triplett (Sep 20 2019 at 14:26, on Zulip):

@pnkfelix I think I'd put it this way:
The easier your target is for people to handle, the less people you need on call.

pnkfelix (Sep 20 2019 at 14:26, on Zulip):

(my question may be in the weeds, but it seems relevant in terms of giving guidance as to when a target could possibly be promoted from tier 3 to tier 2)

Josh Triplett (Sep 20 2019 at 14:26, on Zulip):

@nikomatsakis I did mention those teams, actually.

nikomatsakis (Sep 20 2019 at 14:26, on Zulip):

(ok, I missed it :heart:)

nikomatsakis (Sep 20 2019 at 14:27, on Zulip):

is that a breaking change (I think so)?

I think only Tier 1 should carry any expectation of permanence

Alex Crichton (Sep 20 2019 at 14:27, on Zulip):

to some degree there's also "breaking changes" compatibility within a tier, for example how much of a breaking change is it to increase our kernel requirement for libstd on x86_64 Linux? Increasing the required emscripten version for the emscripten targets? Adding atomics to a wasm target? (etc)

Alex Crichton (Sep 20 2019 at 14:27, on Zulip):

sorry I don't want to pile on too much here

Pietro Albini (Sep 20 2019 at 14:28, on Zulip):

not sure how much release is interested in this -- infra should be at least consulted even on tier 2 though, if only for CI capacity

Josh Triplett (Sep 20 2019 at 14:28, on Zulip):

I just added a new point under all three tiers for instructions/documentation.

Alex Crichton (Sep 20 2019 at 14:28, on Zulip):

@nikomatsakis although permanence is also a good question, Apple itself is killing i686-apple-darwin, so how long should we keep it alive?

nikomatsakis (Sep 20 2019 at 14:28, on Zulip):

(c.f. cygwin)

Pietro Albini (Sep 20 2019 at 14:28, on Zulip):

(we might have to kill that targert soonish due to the CI platform deprecating old images anyway)

nikomatsakis (Sep 20 2019 at 14:29, on Zulip):

it seems like we're getting too afield -- perhaps the best answer is going to be that we should try to have some known people who decide the answer, and outline some rough criteria

Josh Triplett (Sep 20 2019 at 14:29, on Zulip):

:+1:

nikomatsakis (Sep 20 2019 at 14:30, on Zulip):

@Josh Triplett so overall I really liked your proposal, I'd like to give you a chance to steer the conversation here towards the point you would most like to dig into

Josh Triplett (Sep 20 2019 at 14:30, on Zulip):

Roughly speaking, I think "if a target stops meeting the requirements, and especially if it blocks ongoing work in the Rust community, the compiler team will determine if that target needs to be downgraded".

nikomatsakis (Sep 20 2019 at 14:30, on Zulip):

(i.e., we're at the 30 minute point, so I want to make sure we get to everything)

pnkfelix (Sep 20 2019 at 14:30, on Zulip):

does the document cover removing a target entirely? Taking it from tier 3 to nothing?

Josh Triplett (Sep 20 2019 at 14:32, on Zulip):

@pnkfelix It doesn't, but it should. Something like "If a tier 3 target shows no signs of activity and has not built for some time, and removing it would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to people who have previously worked on the platform, to check potential interest."

Josh Triplett (Sep 20 2019 at 14:32, on Zulip):

Sound good?

Josh Triplett (Sep 20 2019 at 14:32, on Zulip):

OK, so focusing on the key points here:

Josh Triplett (Sep 20 2019 at 14:33, on Zulip):

Let's start with "Is there any objection to the description of tier 3?". I'd like to ratify consensus on what (minimal) requirements we have to merge a PR adding a new tier 3 target.

Josh Triplett (Sep 20 2019 at 14:34, on Zulip):

For reference, the text:
At this tier, the Rust project provides no official support for a target, so we
place minimal requirements on the introduction of targets.

- No central decision is required to add a new tier 3 target. Reviewers may
always use their own best judgment regarding the quality of work, and the
suitability of a target for the Rust project.
- If a reviewer wishes to consult a broader team for additional guidance, they
should contact the compiler team.
- If the proposer of a target wishes to appeal the rejection of a target, they
may contact the compiler team.
- Tier 3 targets must use naming consistent with any existing targets; for
instance, a target for a similar CPU or OS should not gratuitously use an
inconsistent name for that CPU or OS. Targets should normally use the same
names as used elsewhere in the broader ecosystem (such as in other toolchains),
unless they have a very good reason to diverge.
- Tier 3 targets may have unusual requirements to build or use, but must not
create legal issues for the Rust project or for developers who work on those
targets.
- Where possible, tier 3 targets may wish to provide documentation for the Rust
community for how to build and run tests for the platform, ideally using
emulation.
- Patches adding or updating tier 3 targets must not break any existing target.

nikomatsakis (Sep 20 2019 at 14:34, on Zulip):

I imagine the "no central decision required" is the most potentially controversial part, but I'm on board. We're basically saying "we'll assume it's ok but be prepared to withdraw if problems arise"

Alex Crichton (Sep 20 2019 at 14:35, on Zulip):

I do think we need to add some level of consensus beyond just the reviewer

Alex Crichton (Sep 20 2019 at 14:35, on Zulip):

for example I would prefer to not add a target which completely changes how libcore/libstd are organized

Josh Triplett (Sep 20 2019 at 14:35, on Zulip):

We're also saying "if you want a central decision, or the reviewer wants a central decision, they should poke the compiler team", so we're saying which team has responsibility.

Josh Triplett (Sep 20 2019 at 14:36, on Zulip):

@Alex Crichton I think that falls under "best judgment regarding the quality of work and the suitability of a target for the Rust project".

Alex Crichton (Sep 20 2019 at 14:36, on Zulip):

well we can always run with it in practice and see how it fares

pnkfelix (Sep 20 2019 at 14:36, on Zulip):

I personally am willing to try the text as written

Pietro Albini (Sep 20 2019 at 14:36, on Zulip):

yeah it sounds good

Josh Triplett (Sep 20 2019 at 14:36, on Zulip):

If a reviewer looks at a PR that massively overhauls libcore in order to make a new target work, and doesn't say "uh, hey, other people should review this", they're kinda not doing their job as a reviewer.

pnkfelix (Sep 20 2019 at 14:36, on Zulip):

and we can tell the reviewers to be conservative in their decisions

nikomatsakis (Sep 20 2019 at 14:36, on Zulip):

If a reviewer looks at a PR that massively overhauls libcore in order to make a new target work, and doesn't say "uh, hey, other people should review this", they're kinda not doing their job as a reviewer.

I think you should make that explicit

Josh Triplett (Sep 20 2019 at 14:37, on Zulip):

Fair. Writing that down...

pnkfelix (Sep 20 2019 at 14:37, on Zulip):

the main question I have is whether the compiler team really will have the knowledge to always make the call.

nikomatsakis (Sep 20 2019 at 14:37, on Zulip):

I think we should say:

- Non-intrusive PRs can be accepted without add'l process

pnkfelix (Sep 20 2019 at 14:37, on Zulip):

but if they don't, I think the compiler team will realize it

pnkfelix (Sep 20 2019 at 14:37, on Zulip):

(and then pull in the additional teams)

nikomatsakis (Sep 20 2019 at 14:37, on Zulip):

yeah, I'm actually not sure compile team is best for this (And elsehwere) but I thikn we're not he worst. I think we may want to instead have it be like release team or something. But I was going to wait till later to raise that.

nikomatsakis (Sep 20 2019 at 14:38, on Zulip):

whichever team it is is going to have to pull in other teams in the end, I think

Alex Crichton (Sep 20 2019 at 14:38, on Zulip):

tbh 90% of the code changes for a new target are typically in libcore/libstd

Alex Crichton (Sep 20 2019 at 14:38, on Zulip):

and like one new target file in the compiler

Pietro Albini (Sep 20 2019 at 14:38, on Zulip):

not sure how the release team has a stake, especially in tier 3 platforms

Josh Triplett (Sep 20 2019 at 14:38, on Zulip):

Done:
- If a proposed target or target-specific patch substantially changes code
shared with other targets (not just target-specific code), the reviewer
should consult the compiler team.

Josh Triplett (Sep 20 2019 at 14:39, on Zulip):

Regarding the release team: right now, I wrote that new tier 1 targets require release team approval, new tier 2 requires compiler team approval, and new tier 3 doesn't need any approval (unless invasive).

Josh Triplett (Sep 20 2019 at 14:39, on Zulip):

Open to changing that, as long as we have a clear path/ownership.

pnkfelix (Sep 20 2019 at 14:40, on Zulip):

since it sounds like tier 2 targets do impose CI building (and some testing?) overhead, we may need T-infrastructure approval for new tier 2, right?

Pietro Albini (Sep 20 2019 at 14:40, on Zulip):

I'd like an infra approval for tier 2 and 1 at least

nikomatsakis (Sep 20 2019 at 14:41, on Zulip):

( that is perhaps somewhat implicit, isn't it? i.e., if the requirement to be tier 2 is to have CI support, and infra adds CI ... )

Josh Triplett (Sep 20 2019 at 14:41, on Zulip):

@Pietro Albini I currently have this in tier 1:

If running the testsuite requires additional infrastructure (such as systems running the target), the target development team shall arrange to provide such resources to the Rust project, to the satisfaction and approval of the Rust infrastructure team.

Should I just change that so that tier 2 and tier 1 need the infrastructure team to sign off on the CI requirements/changes to build and test?

Pietro Albini (Sep 20 2019 at 14:41, on Zulip):

:thumbs_up:

Josh Triplett (Sep 20 2019 at 14:41, on Zulip):

Will do, that's reasonable.

Josh Triplett (Sep 20 2019 at 14:42, on Zulip):

(And I'll mention that that will often happen in the course of reviewing the PR adding the target to CI.)

Josh Triplett (Sep 20 2019 at 14:42, on Zulip):

OK, then let's see if we can make some progress on the higher tiers.

Josh Triplett (Sep 20 2019 at 14:43, on Zulip):

Right now, here's what I have for tier 2. I'm going to additionally add the requirement for infra signoff on CI.

At this tier, the Rust project guarantees that a target builds, and will reject
patches that fail to build on a target. Thus, we place requirements that ensure
the target will not block forward progress of the Rust project.

- Any new tier 2 target requires compiler team approval.
- Any new tier 2 target must have a designated team of developers on call to
consult on target-specific build-breaking issues, or if necessary to develop
target-specific language or library implementation details. (This team should
in almost all cases have at least 2 developers.)
- The target must not place undue burden on Rust developers not specifically
concerned with that target. Rust developers may be expected to not
gratuitously break a tier 2 target, but are not expected to become experts in
every tier 2 target. and are not expected to provide target-specific
implementations for every tier 2 target.
- The target development team should not only fix target-specific issues, but
should use any such issue as an opportunity to educate the Rust community
about portability to their target.
- The target must build reliably in CI.
- Building the target must not take substantially longer than other targets.
- Tier 2 targets must cross-compile from existing targets, and must not require
builds on specific target hardware.
- Where possible, tier 2 targets should to provide documentation for the Rust
community for how to build and run tests for the platform, ideally using
emulation.
- The target development team should regularly run the testsuite for the
target, and should fix any test failures in a reasonably timely fashion.
- All tier 3 requirements apply.

nikomatsakis (Sep 20 2019 at 14:44, on Zulip):

I do think it'd be useful to try and outline the criteria by which compiler team should decide

Josh Triplett (Sep 20 2019 at 14:44, on Zulip):

Highlighting a few specific points: even if we're only build-testing, I think it's important that the target development team regularly run the testsuite and make sure it passes. A target that never passes the testsuite isn't a good look.

nikomatsakis (Sep 20 2019 at 14:44, on Zulip):

for example, how many users is enough?

nikomatsakis (Sep 20 2019 at 14:45, on Zulip):

(or is that not something we should consider)

Josh Triplett (Sep 20 2019 at 14:45, on Zulip):

@nikomatsakis So, tier 1 I did have a requirement for that.

pnkfelix (Sep 20 2019 at 14:45, on Zulip):

Highlighting a few specific points: even if we're only build-testing, I think it's important that the target development team regularly run the testsuite and make sure it passes. A target that never passes the testsuite isn't a good look.

like, there should be a dedicated site where one can see how recently that dev team ran the test suite successfully or something?

Josh Triplett (Sep 20 2019 at 14:45, on Zulip):

Tier 1 I had this: "Tier 1 targets must have substantial, widespread interest within the developer community, and must serve the ongoing needs of multiple production users of Rust."

nikomatsakis (Sep 20 2019 at 14:45, on Zulip):

basically I think it's ok if we want to say "the expectation is that we will approve Tier 2 targets if other requirements are met"

Josh Triplett (Sep 20 2019 at 14:45, on Zulip):

@pnkfelix Not going to require that, just that they actually work on testsuite failures regularly.

nikomatsakis (Sep 20 2019 at 14:46, on Zulip):

but maybe that's too strong -- but if it's not these requirements, then what is the basis for saying no?

Josh Triplett (Sep 20 2019 at 14:46, on Zulip):

@nikomatsakis Reasonable question. I think there's a certain judgment involved, but it's a lot less than tier 1.

Josh Triplett (Sep 20 2019 at 14:46, on Zulip):

Let's talk that out.

Josh Triplett (Sep 20 2019 at 14:46, on Zulip):

I think we shouldn't approve a super-niche target as tier 1.

nikomatsakis (Sep 20 2019 at 14:46, on Zulip):

(I'm just thinking through the questions I will have when somebody asks :)

pnkfelix (Sep 20 2019 at 14:46, on Zulip):

but the CI won't report testsuite failures for tier 2 (because CI doesn't necessarily run tests for that tier), so one won't necessarily know until some user tries it out, right?

nikomatsakis (Sep 20 2019 at 14:47, on Zulip):

basically I think it's ok if we want to say "the expectation is that we will approve Tier 2 targets if other requirements are met"

(to be clear, I meant this only for Tier 2 -- I don't think there should be a "Default yes" for Tier 1 at all)

pnkfelix (Sep 20 2019 at 14:47, on Zulip):

I'm just trying to dig into "the testsuite failing is not a good look" -- its a statement I agree with, and I'm wondering how we can make it easy for T-compiler to be able to respond when someone files an issue about it.

Josh Triplett (Sep 20 2019 at 14:47, on Zulip):

I think it's completely reasonable to approve a niche target for tier 2, as long as there's some interest. But, for instance, I'd want to have some reasonable basis on which to say "we're not supporting m68k even if there are 1-2 dedicated developers trying to keep it alive". ;)

pnkfelix (Sep 20 2019 at 14:48, on Zulip):

how we can make it easy for T-compiler to be able to respond when someone files an issue about it.

(I guess the answer here is that you CC the relevant dev team for such issues)

Josh Triplett (Sep 20 2019 at 14:48, on Zulip):

@pnkfelix I think it suffices to say "the target development team should not only be regularly using the target, they should be testing the target". :)

nikomatsakis (Sep 20 2019 at 14:48, on Zulip):

ok, so it sounds like we want Tier 2 targets to have a "reasonably large community of active users" or smething like that?

Pietro Albini (Sep 20 2019 at 14:48, on Zulip):

about testing the target

nikomatsakis (Sep 20 2019 at 14:48, on Zulip):

(I guess the answer here is that you CC the relevant dev team for such issues)

(this would also fit the ICE-breaker mechanism we are forming)

Pietro Albini (Sep 20 2019 at 14:49, on Zulip):

we had a tier 2 platform a few months ago that developed their own parallel CI and had a bot posting a comment on each PR breaking the build

Pietro Albini (Sep 20 2019 at 14:49, on Zulip):

should we clarify they should not do that in the policy?

Josh Triplett (Sep 20 2019 at 14:49, on Zulip):

I don't think I'd say "reasonably large" (e.g. i686-unknown-uefi is going to be niche by design) but that it needs to have some value for people other than as an exercise.

Pietro Albini (Sep 20 2019 at 14:49, on Zulip):

(we (t-infra) already told that target not to do that in the past)

Josh Triplett (Sep 20 2019 at 14:50, on Zulip):

I don't mind a tier 3 platform existing just as a pure toy with no value other than "ain't that awesome".

nikomatsakis (Sep 20 2019 at 14:50, on Zulip):

hmm so having a parallel CI system seems like good practice, but I guess the part you're objecting to is the part where it implies that the PR author should care ?

Pietro Albini (Sep 20 2019 at 14:50, on Zulip):

yeah that was the concern

Pietro Albini (Sep 20 2019 at 14:50, on Zulip):

because they were implicitly self-promoting themselves to tier 1 level of commitment from PR authors

Josh Triplett (Sep 20 2019 at 14:50, on Zulip):

(Which target was that? You can PM if you'd prefer.)

Josh Triplett (Sep 20 2019 at 14:51, on Zulip):

@Pietro Albini Seems reasonable. A comment that disclaims itself as informational and tags in some response team but says "you don't need to do anything unless we send a patch" seems more acceptable.

nikomatsakis (Sep 20 2019 at 14:51, on Zulip):

I don't think I'd say "reasonably large" (e.g. i686-unknown-uefi is going to be niche by design) but that it needs to have some value for people other than as an exercise.

if you find a good way to phrase this, I'm on board; I think it should be added to the list of Tier 2 criteria though, and I think the "compiler-team approval" bullet should be phrased, "Ultimately, the compiler + infra teams will be the one to formally decide if these criteria are met" or something like that. We probably have enough wiggle room in the "it should not place undue burden on Rust team" to reject things that are a pain anyway.

nikomatsakis (Sep 20 2019 at 14:51, on Zulip):

Seems reasonable. A comment that disclaims itself as informational and tags in some response team but says "you don't need to do anything unless we send a patch" seems more acceptable.

I was going to suggest the same -- that the wording matters a lot.

Pietro Albini (Sep 20 2019 at 14:52, on Zulip):

hmm, I don't want to end in a world where we have tons of bots from different targets posting on a PR

Pietro Albini (Sep 20 2019 at 14:52, on Zulip):

@Alex Crichton had opinions on this too I remember

nikomatsakis (Sep 20 2019 at 14:52, on Zulip):

(I'd also be ok with prohibiting the bot practice explicitly)

Josh Triplett (Sep 20 2019 at 14:52, on Zulip):

Alright. I'll add a comment that automated build/test bots are acceptable, but must not post comments to PRs that put the onus on the PR author or community to fix them, as that would implicitly raise the tier of the target.

nikomatsakis (Sep 20 2019 at 14:53, on Zulip):

(we could instead encourage some kind of dashboard for the target, and maybe link to it from our webpage, so people can get an up-to-date view on the status -- but this is beyond the level of detail (probably) of this doc)

pnkfelix (Sep 20 2019 at 14:53, on Zulip):

(I wonder if labels rather than comments could help here ...?)

Josh Triplett (Sep 20 2019 at 14:53, on Zulip):

OK. Let's leave that issue alone for the moment then.

nikomatsakis (Sep 20 2019 at 14:53, on Zulip):

(Time-check: 7 minutes remaining :)

Josh Triplett (Sep 20 2019 at 14:53, on Zulip):

How do people feel about ratifying the tier 2 policy (with an addition of infra signoff requirements, and some notion of "must be useful")?

pnkfelix (Sep 20 2019 at 14:55, on Zulip):

nit: the phrase "must cross-compile from existing targets" is ambiguous as to whether it means "from all existing targets" or "from some existing target"

pnkfelix (Sep 20 2019 at 14:55, on Zulip):

I'm pretty sure the latter is what is intended

Josh Triplett (Sep 20 2019 at 14:55, on Zulip):

@pnkfelix In practice the requirement is "must compile on the targets used for CI infrastructure". :)

Josh Triplett (Sep 20 2019 at 14:56, on Zulip):

I'll document that more clearly, because that's the real requirement.

Pietro Albini (Sep 20 2019 at 14:56, on Zulip):

with an addition about "no bots" that seems fine for me

Josh Triplett (Sep 20 2019 at 14:57, on Zulip):

@Pietro Albini "no bots" or "no bots that put work on others, and stop if we tell you to stop"?

Tshepang Lekhonkhobe (Sep 20 2019 at 14:57, on Zulip):

what's the advantage of accepting experimental targets (think those that are not expected to reach tier 2), when they could be maintained outside the tree

Pietro Albini (Sep 20 2019 at 14:57, on Zulip):

I'd personally say no bots at all, otherwise we'll get to a point where we will be swarmed

Josh Triplett (Sep 20 2019 at 14:57, on Zulip):

@Tshepang Lekhonkhobe Coordinating work and building from the official tree without divergence/forks.

nikomatsakis (Sep 20 2019 at 14:58, on Zulip):

"no bots" or "no bots that put work on others, and stop if we tell you to stop"?

I think a general clause like "you should not take actions to imply that PR authors should fix your bugs; this includes bots that post on PRs that break your target"

Josh Triplett (Sep 20 2019 at 14:58, on Zulip):

@nikomatsakis Fair. In that case, people can always ask a team if they really want to do that, with an expectation that they'll get a "no".

nikomatsakis (Sep 20 2019 at 14:58, on Zulip):

yep. like, it wouldnt' be better if they used a human to post those comments :)

simulacrum (Sep 20 2019 at 14:59, on Zulip):

Even further -- don't post on our PRs without authorization from infra team (who may reach out to compiler, etc) about tier N targets being broken by that PR

Josh Triplett (Sep 20 2019 at 14:59, on Zulip):

(It might be a reasonable thing to do, for instance, for a tier 2 target that has coordinated with the compiler team to do a "tier 1 dry run", with permission. ;) )

Josh Triplett (Sep 20 2019 at 15:00, on Zulip):

OK: How do people feel about ratifying the tier 2 policy (with an addition of infra signoff requirements, and some notion of "must be useful", and a "no bots or putting work on PR authors" clause)?

Josh Triplett (Sep 20 2019 at 15:00, on Zulip):

(And I'd ask people to look over the tier 1 policy asynchronously and offer feedback.)

Josh Triplett (Sep 20 2019 at 15:01, on Zulip):

I'm planning to submit this policy as documentation linked from the forge tier page and a couple of other places. (Suggestions for a home for it welcome.)

nikomatsakis (Sep 20 2019 at 15:01, on Zulip):

We may want an RFC here; I think we should also try to rationalize our existing tiers into the policy

nikomatsakis (Sep 20 2019 at 15:01, on Zulip):

but we can discuss that async

Pietro Albini (Sep 20 2019 at 15:01, on Zulip):

yeah, an RFC could be good

nikomatsakis (Sep 20 2019 at 15:02, on Zulip):

let me rephrase, I think we do want an RFC :)

simulacrum (Sep 20 2019 at 15:02, on Zulip):

I think an RFC would also give it the appropriate weight so it's not "just" a policy document ratified internally but sort of 'community agreed upon'

Josh Triplett (Sep 20 2019 at 15:02, on Zulip):

@nikomatsakis Some of our existing tiers may inherently be exceptions; we don't, for instance, expect a team on call for x86_64-unknown-linux-gnu. :)

Pietro Albini (Sep 20 2019 at 15:02, on Zulip):

well t-compiler as a whole is on call for that target :P

nikomatsakis (Sep 20 2019 at 15:03, on Zulip):

@Josh Triplett well, that may be true, but I think studying the exceptions will help us see problems

Josh Triplett (Sep 20 2019 at 15:03, on Zulip):

Agreed.

Josh Triplett (Sep 20 2019 at 15:03, on Zulip):

OK. I'll post an RFC then.

Josh Triplett (Sep 20 2019 at 15:03, on Zulip):

Thank you, everyone, for the clear feedback!

Josh Triplett (Sep 20 2019 at 15:03, on Zulip):

We're out of time. I'm really glad we've made progress on this.

Pietro Albini (Sep 20 2019 at 15:03, on Zulip):

thank you for dealing with this mess :heart:

nikomatsakis (Sep 20 2019 at 15:03, on Zulip):

Yes, thanks @Josh Triplett! :heart_eyes:

Josh Triplett (Sep 20 2019 at 15:03, on Zulip):

@Pietro Albini No problem. I'm somewhat motivated; I have three targets I want to move to tier 2, myself. ;)

Josh Triplett (Sep 20 2019 at 15:04, on Zulip):

(Namely, x86_64-linux-kernel,x86_64-unknown-uefi, and i686-unknown-uefi.)

nikomatsakis (Sep 20 2019 at 15:04, on Zulip):

Josh, if you're going to be editing the doc to incorporate suggestions for the meeting, can you also open a PR against the compiler-team repo as the meeting summary? I think it could just include the final doc along with a link to this zulip stream

nikomatsakis (Sep 20 2019 at 15:04, on Zulip):

Also: looking for volunteers to do a summary after the fact.

Example: https://github.com/rust-lang/compiler-team/pull/173 (which summarized our last design meeting)

I'm repeating this, basically

Josh Triplett (Sep 20 2019 at 15:04, on Zulip):

@nikomatsakis Sure, I can do that.

pnkfelix (Sep 20 2019 at 15:05, on Zulip):

(well, zulip streams are not visible to people without zulip accounts, unfortunately...)

nikomatsakis (Sep 20 2019 at 15:05, on Zulip):

but I don't think the summary has to be "minutes" necessarily :)

Josh Triplett (Sep 20 2019 at 15:05, on Zulip):

@pnkfelix Oh. :(

nikomatsakis (Sep 20 2019 at 15:05, on Zulip):

(well, zulip streams are not visible to people without zulip accounts, unfortunately...)

not my problem :P

nikomatsakis (Sep 20 2019 at 15:05, on Zulip):

but also, there is an archive

nikomatsakis (Sep 20 2019 at 15:05, on Zulip):

https://zulip-archive.rust-lang.org/

nikomatsakis (Sep 20 2019 at 15:05, on Zulip):

not the most readable thing ever though :)

nikomatsakis (Sep 20 2019 at 15:05, on Zulip):

but that can be improved...

pnkfelix (Sep 20 2019 at 15:05, on Zulip):

oh i wasn't aware of that

pnkfelix (Sep 20 2019 at 15:06, on Zulip):

when did that go online?

nikomatsakis (Sep 20 2019 at 15:06, on Zulip):

I'm not sure who set that up :) but big thanks to them...

Josh Triplett (Sep 20 2019 at 15:06, on Zulip):

@Pietro Albini On the topic of CI, what would it take for CI to assume that it can run qemu-kvm VMs? That would help for testing UEFI targets, for instance, as well as other interesting x86_64 targets.

pnkfelix (Sep 20 2019 at 15:06, on Zulip):

we should link to that from the compiler website, IMO

nikomatsakis (Sep 20 2019 at 15:06, on Zulip):

sounds good

Pietro Albini (Sep 20 2019 at 15:06, on Zulip):

@Josh Triplett I think we're already running some qemu tests on CI

Josh Triplett (Sep 20 2019 at 15:06, on Zulip):

@Pietro Albini With KVM acceleration, though?

pnkfelix (Sep 20 2019 at 15:07, on Zulip):

I gotta go, but before I do, thanks everyone in @T-compiler/meeting for attending!

Pietro Albini (Sep 20 2019 at 15:07, on Zulip):

that I'm not sure, we'd need to look into it

simulacrum (Sep 20 2019 at 15:18, on Zulip):

@pnkfelix @nikomatsakis zulip archive went online about a month ago, we're using a prototype from the zulip folks -- see some discussion here: https://rust-lang.zulipchat.com/#narrow/stream/122653-zulip/topic/public.20logs.20.2F.20streams

simulacrum (Sep 20 2019 at 15:19, on Zulip):

repo is https://github.com/rust-lang/zulip_archive feel free to ping me for redeploys and such

centril (Sep 20 2019 at 18:55, on Zulip):

Sadly missed this meeting;

the ongoing needs of multiple production users of Rust."

This feels vague -- I'd expect tier 1 toolchains to serve the needs of a huge number of users (and not from the same company)

centril (Sep 20 2019 at 18:56, on Zulip):

(like in the 1000s)

Josh Triplett (Sep 20 2019 at 19:49, on Zulip):

@Centril I'll clarify. By "multiple production users" I meant distinct entities.

Josh Triplett (Sep 20 2019 at 19:49, on Zulip):

Many people but all from the same company doesn't count as "multiple production users", even if they work on different products.

Josh Triplett (Sep 20 2019 at 23:46, on Zulip):

Minutes at https://github.com/rust-lang/compiler-team/pull/181
@nikomatsakis

nagisa (Sep 21 2019 at 04:49, on Zulip):

Missed the mtg too. As somebody who kinda-sorta looks after a bunch of T2/T3 architectures, I think their current status T2/T3 status is perfectly fine, but we should have a more precise definition of how much each target is supported

nagisa (Sep 21 2019 at 04:49, on Zulip):

Rather than a T1-3 a table with Y/N for various things would help, where things would be: binaries provided, tests run, can x-compile to etc.

nagisa (Sep 21 2019 at 04:50, on Zulip):

Even then targets which have N for all of the columns (say AVR) make sense.

centril (Sep 21 2019 at 11:37, on Zulip):

Yes but "multitude" can mean 5, 10, 100, ...

Josh Triplett (Sep 22 2019 at 18:59, on Zulip):

@centril I don't want to give a hard number. It's up to the team to judge. It also balances with other factors, such as difficulty of building and maintaining the target.

gnzlbg (Sep 24 2019 at 13:21, on Zulip):

but we should have a more precise definition of how much each target is supported

@nagisa yeah, having to look in the specification files or CI to see if compiler-builtins is built, libcore is built, libstd is built, whether there are CI tests running, etc. is a pain.

gnzlbg (Sep 24 2019 at 13:22, on Zulip):

Another thing that's hard to tell is whether one of the Tier-1 compilers is actually able to cross-compile for a different target

gnzlbg (Sep 24 2019 at 13:23, on Zulip):

AFAICT we don't test that, e.g., x86_64-unknown-linux-gnu is able to cross-compile, e.g., compiler-builtins or libcore for all the target triplets it accepts

gnzlbg (Sep 24 2019 at 13:24, on Zulip):

So we end up with target-triples in tree that are actually impossible to target

Last update: Nov 22 2019 at 05:20UTC