Stream: t-compiler

Topic: #54818 weekly meeting 2019-01-17


pnkfelix (Jan 17 2019 at 14:33, on Zulip):

hi everyone in @T-compiler/meeting ; I'm going to be some pre-triage before the meeting starts in ~27 minutes.

pnkfelix (Jan 17 2019 at 14:34, on Zulip):

first up: P-high issues

pnkfelix (Jan 17 2019 at 14:34, on Zulip):

"OSX: use after free in thread_local when a TLS location isn't initialized until destruction of another TLS location" #57534

pnkfelix (Jan 17 2019 at 14:35, on Zulip):

This seems like it was erroneously tagged as T-compiler

pnkfelix (Jan 17 2019 at 14:35, on Zulip):

(also seems to have a patch)

pnkfelix (Jan 17 2019 at 14:36, on Zulip):

next "[NLL] Bad higher ranked subtype error" #57374

pnkfelix (Jan 17 2019 at 14:37, on Zulip):

This was discussed in NLL meeting last week but I don't think we touched on it last night.

pnkfelix (Jan 17 2019 at 14:37, on Zulip):

Adding self to assignees list to try to ensure we make progress this week.

pnkfelix (Jan 17 2019 at 14:38, on Zulip):

next: "Confusing error message associated with universe transition: 'one type is more general than the other'" #57362

pnkfelix (Jan 17 2019 at 14:39, on Zulip):

it seems like things are progressing here between the notes written by @nikomatsakis and the fact that @lqd self-assigned themselves within the last 24 hours

pnkfelix (Jan 17 2019 at 14:39, on Zulip):

next: "PhantomData fields in repr(C) structs change ABI on aarch64" #56877

pnkfelix (Jan 17 2019 at 14:41, on Zulip):

okay it looks like things have been progressing well here (it even has a PR #57645)

pnkfelix (Jan 17 2019 at 14:42, on Zulip):

next: "prohibit "two-phase borrows" with existing borrows?" #56254

pnkfelix (Jan 17 2019 at 14:44, on Zulip):

there was some movement here in the comment thread two weeks ago, and also @Matthew Jasper has made progress exploring the proposed step 1, namely make match desugaring not use two-phase borrows (2PB) in PR #57609

pnkfelix (Jan 17 2019 at 14:44, on Zulip):

so I think things are progressing here. There were definite hiccups largely due to my absence

pnkfelix (Jan 17 2019 at 14:45, on Zulip):

I'm going to put myself back on assignee list for #56254 to try to ensure I get back on board with it

pnkfelix (Jan 17 2019 at 14:46, on Zulip):

next: "two-phase-borrows need a specification" #46901

pnkfelix (Jan 17 2019 at 14:46, on Zulip):

ugh should this remain P-high ...

pnkfelix (Jan 17 2019 at 14:46, on Zulip):

I'll make a note to that effect on the issue

pnkfelix (Jan 17 2019 at 14:47, on Zulip):

but I will also leave it at P-high in the hopes that I will actually do something about it now that I am back

pnkfelix (Jan 17 2019 at 14:48, on Zulip):

next (and last P-high issue): "figure out how to integrate constants and the MIR type checker" #46702

pnkfelix (Jan 17 2019 at 14:48, on Zulip):

@Matthew Jasper self-assigned themselves to this a little less than a week ago.

pnkfelix (Jan 17 2019 at 14:50, on Zulip):

okay that's all the P-highs

pnkfelix (Jan 17 2019 at 14:50, on Zulip):

no beta-nominations on the list currently.

pnkfelix (Jan 17 2019 at 14:50, on Zulip):

no stable-nominations either

pnkfelix (Jan 17 2019 at 14:51, on Zulip):

next: stable-to-beta regressions

pnkfelix (Jan 17 2019 at 14:51, on Zulip):

first: "Panic in nightly rustc_errors::CodeSuggestion::splice_lines" #57521

pnkfelix (Jan 17 2019 at 14:52, on Zulip):

marking P-high and assigning self.

pnkfelix (Jan 17 2019 at 14:53, on Zulip):

all remaining stable-to-beta regressions are T-rustdoc

pnkfelix (Jan 17 2019 at 14:53, on Zulip):

next: stable-to-nightly regressions

pnkfelix (Jan 17 2019 at 14:53, on Zulip):

first: "ICE with incremental compiling when renaming variable" #57692

pnkfelix (Jan 17 2019 at 14:54, on Zulip):

marking P-high and assigning to @mw (who already has a PR up for it)

pnkfelix (Jan 17 2019 at 14:55, on Zulip):

next: "ICE on nightly when dereferencing boxed Iterator trait object" #57673

pnkfelix (Jan 17 2019 at 14:56, on Zulip):

community has already provided info on bisection (yay)

pnkfelix (Jan 17 2019 at 14:56, on Zulip):

labelling P-high and assigning to self for further investigation.

pnkfelix (Jan 17 2019 at 14:57, on Zulip):

next: "Diagnostics: mismatched types show wrong because of this statement" #57664

pnkfelix (Jan 17 2019 at 14:57, on Zulip):

@Esteban Küber says that their PR #57020 injected this. Assigning to @Esteban Küber for now (and marking P-high).

pnkfelix (Jan 17 2019 at 14:59, on Zulip):

next: "Regression in trait bounds that are redundant with associated type's HRTB' #57639

pnkfelix (Jan 17 2019 at 15:00, on Zulip):

hmm.

nikomatsakis (Jan 17 2019 at 15:00, on Zulip):

probably assign to me

nikomatsakis (Jan 17 2019 at 15:00, on Zulip):

almost certainly due to the universes work

nikomatsakis (Jan 17 2019 at 15:00, on Zulip):

though I've not read the whole issue yet

pnkfelix (Jan 17 2019 at 15:00, on Zulip):

seems like a legit regression. Okay will assign to @nikomatsakis

pnkfelix (Jan 17 2019 at 15:02, on Zulip):

(I wasn't sure if the change might have been a bug fix, but if the given code does indeed compile after uncommenting the lines indicated, that seems like one should not blame it on hypothetical unsoundness. That or there's a deeper unsoundness issue...)

pnkfelix (Jan 17 2019 at 15:02, on Zulip):

next: "rustc -vV segmentation fault" #57518 . This is on NixOS

pnkfelix (Jan 17 2019 at 15:03, on Zulip):

@nagisa said they can reproduce, which leads me to wonder if I should assign it to them. Also I am wondering if this is P-medium.

pnkfelix (Jan 17 2019 at 15:04, on Zulip):

I already discussed #57362

pnkfelix (Jan 17 2019 at 15:05, on Zulip):

last stable-to-nightly regression: "nightly rustc --version hangs forever" #56736

pnkfelix (Jan 17 2019 at 15:05, on Zulip):

oh right this is T-infra, not T-compiler

pnkfelix (Jan 17 2019 at 15:06, on Zulip):

Note the recent comment from turboladen saying they see this in a context without running ESET

pnkfelix (Jan 17 2019 at 15:06, on Zulip):

anyway I don't think this is our issue to resolve even with that recent comment

pnkfelix (Jan 17 2019 at 15:07, on Zulip):

okay so maybe lets actually start the meeting now? @T-compiler/meeting ?

pnkfelix (Jan 17 2019 at 15:08, on Zulip):

Beyond the notes I wrote above about some last minute triage...

pnkfelix (Jan 17 2019 at 15:08, on Zulip):

there's this issue that @Oli opened that is waiting on a number of teams, including our own: "Automatically open an issue when a tool breaks" #56951

pnkfelix (Jan 17 2019 at 15:09, on Zulip):

but I think most of T-compiler has already checked off their check boxes on this.

pnkfelix (Jan 17 2019 at 15:10, on Zulip):

beyond that, there are four nominated issues here

pnkfelix (Jan 17 2019 at 15:10, on Zulip):

oh wait, lets see

pnkfelix (Jan 17 2019 at 15:11, on Zulip):

#57642 is almost certainly meant just for NLL

pnkfelix (Jan 17 2019 at 15:11, on Zulip):

well, maybe not

pnkfelix (Jan 17 2019 at 15:11, on Zulip):

but either way

pnkfelix (Jan 17 2019 at 15:11, on Zulip):

I also think it is probably a duplicate of other bugs I mentioned elswehere

nikomatsakis (Jan 17 2019 at 15:11, on Zulip):

actually not quite

nikomatsakis (Jan 17 2019 at 15:11, on Zulip):

in particular, it highlights one case that is not an error in NLL but prob should be

pnkfelix (Jan 17 2019 at 15:12, on Zulip):

(its the "one type is more general than the other" thing that we saw related to the universes changes, no?)

nikomatsakis (Jan 17 2019 at 15:12, on Zulip):

whereas the others are more about diagnostics

pnkfelix (Jan 17 2019 at 15:12, on Zulip):

okay so maybe there are two distinct bugs that should be tracked here

pnkfelix (Jan 17 2019 at 15:12, on Zulip):

and one is a dupe. the other is NLL.

nikomatsakis (Jan 17 2019 at 15:12, on Zulip):

I will edit it -- it falls into a category of "migrate blockers" -- that is, things that must be fixed before we turn off migration mode

pnkfelix (Jan 17 2019 at 15:12, on Zulip):

okay cool, thanks.

nikomatsakis (Jan 17 2019 at 15:12, on Zulip):

we need a label for that I guess

pnkfelix (Jan 17 2019 at 15:13, on Zulip):

But it is indeed nominated for NLL meeting ,right?

nikomatsakis (Jan 17 2019 at 15:13, on Zulip):

("migrate blocker" is obviously a misleading name, since it doesn't block migration mode)

nikomatsakis (Jan 17 2019 at 15:13, on Zulip):

presumably

pnkfelix (Jan 17 2019 at 15:13, on Zulip):

okay

nikomatsakis (Jan 17 2019 at 15:13, on Zulip):

we can leave it for that for now, not urgent

pnkfelix (Jan 17 2019 at 15:13, on Zulip):

next nominated issue is "if goto wrong branch in some cases on mips-unknown-linux-musl" #57631

pnkfelix (Jan 17 2019 at 15:13, on Zulip):

looks like an LLVM issue,

pnkfelix (Jan 17 2019 at 15:14, on Zulip):

not sure how best to prioritize

pnkfelix (Jan 17 2019 at 15:14, on Zulip):

its already assigned to nikic

pnkfelix (Jan 17 2019 at 15:14, on Zulip):

@nagisa do you want to chime in, since you nominated this?

nikomatsakis (Jan 17 2019 at 15:14, on Zulip):

nikic is @Nikita Popov (I think)

pnkfelix (Jan 17 2019 at 15:15, on Zulip):

(mouse hover on github agrees with @nikomatsakis about identity of nikic)

pnkfelix (Jan 17 2019 at 15:16, on Zulip):

well until @nagisa speaks up I guess I'll leave it nominated

pnkfelix (Jan 17 2019 at 15:16, on Zulip):

next:[do not merge] Measure performance impact of local interners" #57214 "

nikomatsakis (Jan 17 2019 at 15:17, on Zulip):

I'm not sure what's the best way to handle a decision like this; I could see us discussing it at the all hands perhaps

mw (Jan 17 2019 at 15:17, on Zulip):

yeah

mw (Jan 17 2019 at 15:18, on Zulip):

memory usage profiling is rather noisy unfortunately

mw (Jan 17 2019 at 15:18, on Zulip):

but it would be awesome to get rid of 'lcx in TyCtxt

nikomatsakis (Jan 17 2019 at 15:19, on Zulip):

actually

nikomatsakis (Jan 17 2019 at 15:19, on Zulip):

well, I agree, but I was just wondering if it'd be worth talking a bit over the names and things

nikomatsakis (Jan 17 2019 at 15:19, on Zulip):

(e.g., conventions for what to name lifetimes, etc)

pnkfelix (Jan 17 2019 at 15:20, on Zulip):

lets plan to talk about it at all hands

pnkfelix (Jan 17 2019 at 15:21, on Zulip):

next nominated issue: "Various cosmetic and minor changes" #57016

nikomatsakis (Jan 17 2019 at 15:22, on Zulip):

I do want us to try and have some discussion about this; at least it's been pending for a while.

pnkfelix (Jan 17 2019 at 15:22, on Zulip):

Even if we don't have rules that we enforce

pnkfelix (Jan 17 2019 at 15:23, on Zulip):

it would be good to at least document the recommended style...

nikomatsakis (Jan 17 2019 at 15:23, on Zulip):

I think my feeling remains roughly the same as what I wrote initially:

nikomatsakis (Jan 17 2019 at 15:23, on Zulip):

it would be good to at least document the recommended style...

I have mixed feelings.

pnkfelix (Jan 17 2019 at 15:23, on Zulip):

(so that someone writing new code has something to refer to)

nikomatsakis (Jan 17 2019 at 15:23, on Zulip):

that requires us to have a recommended style

pnkfelix (Jan 17 2019 at 15:23, on Zulip):

Though to be fair my usual preference is to infer the style in a local fashion

pnkfelix (Jan 17 2019 at 15:23, on Zulip):

(i.e. figure it out from the file I'm in)

centril (Jan 17 2019 at 15:23, on Zulip):

(fwiw, this is not my turf, but I'm much more concerned about 7k LOC spaghetti files...)

oli (Jan 17 2019 at 15:24, on Zulip):

As long as we don't end in edit wars I don't care about style changes

oli (Jan 17 2019 at 15:24, on Zulip):

basically any disputed point should mean that we don't change it

nikomatsakis (Jan 17 2019 at 15:25, on Zulip):

(cc @Alexander Regueiro btw)

nagisa (Jan 17 2019 at 15:25, on Zulip):

Sorry for being late. Had to prepare my hotpot.

centril (Jan 17 2019 at 15:25, on Zulip):

@nikomatsakis i.e. what I would try to enforce is small functions without a lot of rightward drift and such...

pnkfelix (Jan 17 2019 at 15:25, on Zulip):

it sounds like a lot of things add up to "we won't be merging this PR as is"

nagisa (Jan 17 2019 at 15:25, on Zulip):

(if you want to return to anything)

nikomatsakis (Jan 17 2019 at 15:25, on Zulip):

@centril I think that's an orthogonal issue

centril (Jan 17 2019 at 15:26, on Zulip):

ye somewhat

pnkfelix (Jan 17 2019 at 15:26, on Zulip):

and so we then need to figure out what feedback to provide regarding where @Alexander Regueiro should take it.

nikomatsakis (Jan 17 2019 at 15:27, on Zulip):

certainly we'd want to split out the lib changes

nikomatsakis (Jan 17 2019 at 15:27, on Zulip):

(public facing things)

nikomatsakis (Jan 17 2019 at 15:29, on Zulip):

I'm torn on the rest, but I guess @Alexander Regueiro and I can kind of categorize them. I feel "fine" about landing things like e.g. to E.g. or what have you, but I'm really nervous about adopting some kind of English style manual.

pnkfelix (Jan 17 2019 at 15:29, on Zulip):

Is it worth taking the time to catalogue the distinct changes that were proposed, and then trying to get consensus amongst the team about whether each change is universally good? That sounds like a stupid way to waste peoples time, but I'm also not sure how else to actually give useful feedback here.

nikomatsakis (Jan 17 2019 at 15:29, on Zulip):

This is the one thing that frustrates me about such PRs: because it kind of forces our hand into this exercise, and I don't think it's a good use of time. =)

davidtwco (Jan 17 2019 at 15:30, on Zulip):

IMO, as long as the current state of things is reasonable (not incorrect or agregiously formatted), I lean towards leaving things as is - discussions on formatting and comment styles can be prone to bikeshed and conflict. Just my 2c.

pnkfelix (Jan 17 2019 at 15:30, on Zulip):

so then maybe we just say we aren't going ot take this.

centril (Jan 17 2019 at 15:30, on Zulip):

@nikomatsakis > but I'm really nervous about adopting some kind of English style manual.

I wouldn't do that as requirement; but I'd still allow fixes...

nikomatsakis (Jan 17 2019 at 15:30, on Zulip):

So, I say we don't do it, and we adopt the @Oli "rule" of just kind of dropping objected changes

nikomatsakis (Jan 17 2019 at 15:31, on Zulip):

ok, let's reject the PR for now (it would need a lot of work anyway), and leave the consensus as:

drive-by style changes are ok, but we try not to make a big deal out of it and don't have "official" rules.

nikomatsakis (Jan 17 2019 at 15:31, on Zulip):

At least that's my proposal :)

pnkfelix (Jan 17 2019 at 15:31, on Zulip):

okay. I'll post a comment trying to summarize our seeming consensus (the consensus being that we cannot expect to reach consensus for the changes en masse.)

mw (Jan 17 2019 at 15:31, on Zulip):

sgtm

Wesley Wiser (Jan 17 2019 at 15:32, on Zulip):

It would probably also help if each individual set of changes were in their own commit. One for e.g. -> E.g., one for one space after ., etc. It would be a lot easier to review then

nikomatsakis (Jan 17 2019 at 15:32, on Zulip):

I changed my wording to "style changes", since "fixes" implies there is a right thing =)

pnkfelix (Jan 17 2019 at 15:32, on Zulip):

@Wesley Wiser yeah, multiple people told @Alexander Regueiro that on the PR itself.

centril (Jan 17 2019 at 15:32, on Zulip):

@Wesley Wiser I would even split them into separate PRs

centril (Jan 17 2019 at 15:32, on Zulip):

cause that makes T-release happy

pnkfelix (Jan 17 2019 at 15:32, on Zulip):

so... lets try to backtrack

pnkfelix (Jan 17 2019 at 15:33, on Zulip):

@nagisa can you explain your earlier nomination?

nikomatsakis (Jan 17 2019 at 15:33, on Zulip):

(which is that?)

pnkfelix (Jan 17 2019 at 15:33, on Zulip):

nomination of #57631 that is

nagisa (Jan 17 2019 at 15:33, on Zulip):

Sure. Its a codegen bug and therefore should be fixed/prioritized. As those usually tend to lead to soundness issues (especially if they are on our side)

nagisa (Jan 17 2019 at 15:34, on Zulip):

I marked it P-medium on my own discretion since this is a MIPS-specific bug and has been narrowed down by @Nikita Popov.

nikomatsakis (Jan 17 2019 at 15:37, on Zulip):

do we think a fix is forthcoming?

nikomatsakis (Jan 17 2019 at 15:37, on Zulip):

or, it's an LLVM bug, right?

nagisa (Jan 17 2019 at 15:37, on Zulip):

Possibly, depends on how well maintained MIPS backend is upstream

nagisa (Jan 17 2019 at 15:38, on Zulip):

Yeah, it is a bug in fastisel, which is the primary reason why I went for P-medium – there is little chance that it will have any impact on correctness of other backends.

nikomatsakis (Jan 17 2019 at 15:38, on Zulip):

OK

nikomatsakis (Jan 17 2019 at 15:38, on Zulip):

seems...ok I guess

nagisa (Jan 17 2019 at 15:38, on Zulip):

and MIPS is not much of a priority for us.

nagisa (Jan 17 2019 at 15:40, on Zulip):

Should we move on?

nikomatsakis (Jan 17 2019 at 15:40, on Zulip):

seems like it

nikomatsakis (Jan 17 2019 at 15:40, on Zulip):

other nominated issues, @pnkfelix ?

pnkfelix (Jan 17 2019 at 15:41, on Zulip):

nope don't thinkk so

pnkfelix (Jan 17 2019 at 15:41, on Zulip):

so

pnkfelix (Jan 17 2019 at 15:41, on Zulip):

@nagisa I think there was some issue I had asked if you could take

pnkfelix (Jan 17 2019 at 15:41, on Zulip):

please check back log for that if you can

nagisa (Jan 17 2019 at 15:42, on Zulip):

I know what you’re talking about.

pnkfelix (Jan 17 2019 at 15:42, on Zulip):

beyond that, we have these standing agenda items to e.g. go through unprioritized T-compiler issues

pnkfelix (Jan 17 2019 at 15:42, on Zulip):

holy cow there's 76 open unprioritized T-compiler ICE's ...

pnkfelix (Jan 17 2019 at 15:43, on Zulip):

T-compiler unprioritized ICEs

nikomatsakis (Jan 17 2019 at 15:43, on Zulip):

fun

pnkfelix (Jan 17 2019 at 15:43, on Zulip):

I feel like every time I actually reach these bullet items I immediately dispair

pnkfelix (Jan 17 2019 at 15:43, on Zulip):

(despair?)

pnkfelix (Jan 17 2019 at 15:43, on Zulip):

anyway

centril (Jan 17 2019 at 15:43, on Zulip):

(dear lord... that's a lot...)

pnkfelix (Jan 17 2019 at 15:44, on Zulip):

Its not somethign we all need to sit through synchronously

nikomatsakis (Jan 17 2019 at 15:44, on Zulip):

I wonder how we should deal with this

Vadim Petrochenkov (Jan 17 2019 at 15:44, on Zulip):

By the way, when T-compiler label is supposed to be set?

nikomatsakis (Jan 17 2019 at 15:44, on Zulip):

(reminds me of the old project-wide triage meeting)

Vadim Petrochenkov (Jan 17 2019 at 15:44, on Zulip):

I have no idea.

nikomatsakis (Jan 17 2019 at 15:45, on Zulip):

@Vadim Petrochenkov I guess "when it's an issue that the compiler team should be involved in fixing"?

Vadim Petrochenkov (Jan 17 2019 at 15:45, on Zulip):

(I usually just add I-nominated.)

nikomatsakis (Jan 17 2019 at 15:45, on Zulip):

I feel like all issues should have at least one T-

centril (Jan 17 2019 at 15:45, on Zulip):

@nikomatsakis suggestion: pick some people, then give them ranges to triage, e.g. X gets 1-10, Y gets 11-20, Z gets 21-30, ...

nagisa (Jan 17 2019 at 15:45, on Zulip):

We should probably allow for some discretion in terms of P-* flags. They always felt to me like something that need consensus to set.

pnkfelix (Jan 17 2019 at 15:45, on Zulip):

Well, if something is fixable via a change to librustc[_*] or libsyntax, then usually I figure that's T-compiler.

nagisa (Jan 17 2019 at 15:45, on Zulip):

that is, I currently view P-less ICEs as simply P-medium-ish

nikomatsakis (Jan 17 2019 at 15:45, on Zulip):

suggestion: pick some people, then give them ranges to triage, e.g. X gets 1-10, Y gets 11-20, Z gets 21-30, ...

parallelization seems good

nikomatsakis (Jan 17 2019 at 15:46, on Zulip):

this is sounding to me like a kind of "working group" =)

pnkfelix (Jan 17 2019 at 15:46, on Zulip):

76 isn't even that badc

pnkfelix (Jan 17 2019 at 15:46, on Zulip):

we have 1,013 open issues tagged with T-compiler

nikomatsakis (Jan 17 2019 at 15:46, on Zulip):

it's not, I suspect the real number if higher =)

centril (Jan 17 2019 at 15:46, on Zulip):

WG seems tad overkill...

centril (Jan 17 2019 at 15:46, on Zulip):

Labeling is also mostly a T-release concern

nikomatsakis (Jan 17 2019 at 15:47, on Zulip):

maybe you think WG means more than I do

nikomatsakis (Jan 17 2019 at 15:47, on Zulip):

I basically mean: a few folks to lead the effort, a set of volunteers, and some set synchronizaton times to come together adn review the results

nikomatsakis (Jan 17 2019 at 15:47, on Zulip):

rinse, repeat

centril (Jan 17 2019 at 15:47, on Zulip):

ye, thats what it means to me also

nikomatsakis (Jan 17 2019 at 15:47, on Zulip):

we could finish this off in a few weeks I imagine if we wanted

nikomatsakis (Jan 17 2019 at 15:47, on Zulip):

(the backlog)

centril (Jan 17 2019 at 15:47, on Zulip):

@nikomatsakis what is the purpose of the WG? triage all outstanding issues or just I-ICEs?

nikomatsakis (Jan 17 2019 at 15:47, on Zulip):

well, the 76, noty so sure about the 1000 :)

nikomatsakis (Jan 17 2019 at 15:48, on Zulip):

it doesn't really matter if we call it a WG or not, but basically we're suggesting some other kind of triage process to deal with "older stuff", right?

nikomatsakis (Jan 17 2019 at 15:48, on Zulip):

I do also feel like P-low and P-medium can be a kind of "black hole" where stuff disappears, it's hard for us to table something for a few months and then come back to it, for example

pnkfelix (Jan 17 2019 at 15:49, on Zulip):

We should probably allow for some discretion in terms of P-* flags. They always felt to me like something that need consensus to set.

This is an interesting point. Obviously I have been feeling free to go ahead and assign P-labels as long as I announced it either at a meeting or during pre-meeting triage

nagisa (Jan 17 2019 at 15:49, on Zulip):

Yeah, which is why I’d rather the ICEs not have any P-tag at all, unless we are sure we want to make it P-high

nikomatsakis (Jan 17 2019 at 15:49, on Zulip):

oh, this all reminds me:

:trumpet: we have a steering meeting tomorrow :trumpet:

thoughts on what we should discuss are welcome =) I have a few ideas

pnkfelix (Jan 17 2019 at 15:49, on Zulip):

how best to give other people that freedom?

qmx (Jan 17 2019 at 15:49, on Zulip):

bot?

nagisa (Jan 17 2019 at 15:49, on Zulip):

:trumpet: we have a steering meeting tomorrow :trumpet:

We should also cancel the meetings between february 4 and 8 :slight_smile:

nikomatsakis (Jan 17 2019 at 15:49, on Zulip):

ah..yes :)

pnkfelix (Jan 17 2019 at 15:50, on Zulip):

perhaps make a dedicated triaging channel zulip topic where a person or bot fires off every change in P-setting to an issue or PR ?

centril (Jan 17 2019 at 15:50, on Zulip):

but basically we're suggesting some other kind of triage process to deal with "older stuff", right?

I have no idea... =P

-- what I would like is to kill off all the I-unsound issues

nagisa (Jan 17 2019 at 15:50, on Zulip):

how best to give other people that freedom?

just make it clear that they can and should apply the tags at their own discretion?

pnkfelix (Jan 17 2019 at 15:50, on Zulip):

@nagisa that's fine for the tag like P-high that gets regular review

pnkfelix (Jan 17 2019 at 15:51, on Zulip):

but like @nikomatsakis said, P-medium/P-low ends up as a potential pit

nikomatsakis (Jan 17 2019 at 15:51, on Zulip):

I feel like we should fix that

centril (Jan 17 2019 at 15:51, on Zulip):

I sometimes assign P-* tags to issues during T-release triage

centril (Jan 17 2019 at 15:51, on Zulip):

y'all will need to sync this up with the release team

Vadim Petrochenkov (Jan 17 2019 at 15:51, on Zulip):

I treat everything as "P-high" and "the rest" as well.

nikomatsakis (Jan 17 2019 at 15:51, on Zulip):

basically I think having some kind of regular review that ensures we are turning over issues feels important to me; it could also be coordinated with reviewing recent changes in priority

pnkfelix (Jan 17 2019 at 15:51, on Zulip):

we certainly could attempt to more regularly review P-medium at least

nikomatsakis (Jan 17 2019 at 15:51, on Zulip):

y'all will need to sync this up with the release team

why?

nagisa (Jan 17 2019 at 15:51, on Zulip):

Here’s another thought. There's a lot of duplication between I-nominated and P-high. Why not just get rid of I-nominated, and mark all those issues P-high instead, removing or reducing the priority tag once we get to the issue?

pnkfelix (Jan 17 2019 at 15:52, on Zulip):

e.g. look at the tickets that fall into 1 mod 10, 2 mod 10, ... each week

nagisa (Jan 17 2019 at 15:52, on Zulip):

duplication in the purpose that is (as in: somebody should detinitely look at this)

nikomatsakis (Jan 17 2019 at 15:52, on Zulip):

(sorry for curt message: I'm just really not quite @centril how this relates to the T-release team)

centril (Jan 17 2019 at 15:52, on Zulip):

@nikomatsakis cause T-release does a lot of the issue triage and labeling; so we should have coordination in labeling policy

nikomatsakis (Jan 17 2019 at 15:53, on Zulip):

Here’s another thought. There's a lot of duplication between I-nominated and P-high. Why not just get rid of I-nominated, and mark all those issues P-high instead, removing or reducing the priority tag once we get to the issue?

hmm. that..seems ok, we could call it "p-high" and just indicate that it's high priority to resolve such-and-such? they are a bit different, but maybe not so different that it matters? not sure.

nikomatsakis (Jan 17 2019 at 15:53, on Zulip):

it's certainly true that we often don't get to nominated issues for a while

nikomatsakis (Jan 17 2019 at 15:53, on Zulip):

(but then again if we put them up front, would that cause problems not getting to other things?)

nikomatsakis (Jan 17 2019 at 15:54, on Zulip):

@centril ok. that makes sense, though I think that ultimately we are talking about our own internal priorities here in terms of making sure we track what to fix, and it probably wont' affect release team very much. This is mostly about the non burning issues, I think

pnkfelix (Jan 17 2019 at 15:54, on Zulip):

I dunno. My hope had been that we could try to establish a protocol where as part of nominating an issue, you would actually write down what the specific point of discussion was to be

pnkfelix (Jan 17 2019 at 15:54, on Zulip):

P-high doesn't always imply that

pnkfelix (Jan 17 2019 at 15:54, on Zulip):

now, of course, I-nominated hasn't successfully implied either

pnkfelix (Jan 17 2019 at 15:55, on Zulip):

but right now, when I see I-nominated, I feel pressured to find out "why was this nominated"

nagisa (Jan 17 2019 at 15:55, on Zulip):

For me I-nominated was always "somebody should look at this and P-flag is wanted here"

centril (Jan 17 2019 at 15:55, on Zulip):

@nikomatsakis OK; sure

As for I-nominated and P-high; make sure that y'all don't remove the labels themselves because I know that at least the latter is used by other teams

nagisa (Jan 17 2019 at 15:55, on Zulip):

which comes back to P-flags need consensus.

pnkfelix (Jan 17 2019 at 15:55, on Zulip):

vs P-high, where I feel somewhat free to re-assign a P-flag if I decide P-high was unwwarnted.

Vadim Petrochenkov (Jan 17 2019 at 15:56, on Zulip):

This is mostly about the non burning issues

I'm not even sure it's useful to label non-burning issues at all beside "thematic" labels like A-macros/A-visibility/etc

pnkfelix (Jan 17 2019 at 15:56, on Zulip):

(and of course where such reassignment is announced amongst T-compiler)

pnkfelix (Jan 17 2019 at 15:56, on Zulip):

This is mostly about the non burning issues

I'm not even sure it's useful to label non-burning issues at all beside "thematic" labels like A-macros/A-visibility/etc

It can be useful when one is attempted to review history

pnkfelix (Jan 17 2019 at 15:56, on Zulip):

e.g. "didn't we fix this, lets find the bug that sounded like this"

nikomatsakis (Jan 17 2019 at 15:56, on Zulip):

I dunno. My hope had been that we could try to establish a protocol where as part of nominating an issue, you would actually write down what the specific point of discussion was to be

yes -- I was imagining that P-high might work same way, where you would leave a note when setting the flag about why you set it. But I tend to agree they are perhaps slightly different things.

pnkfelix (Jan 17 2019 at 15:57, on Zulip):

/me has to jet

nikomatsakis (Jan 17 2019 at 15:57, on Zulip):

@Vadim Petrochenkov you mean with a priority? I too am not sure how much it matters =) this is partly why we have a very flat priority scheme. I think the plan with P-low initially was that, once something is marked P-low, it is not retriaged ever.

nikomatsakis (Jan 17 2019 at 15:57, on Zulip):

but p-medium would be

nikomatsakis (Jan 17 2019 at 15:58, on Zulip):

anyway, I gotta go to another meeting too =) thanks all, good food for thought

Vadim Petrochenkov (Jan 17 2019 at 15:58, on Zulip):

I may make sense if you have a team of people actively working on issue fixes.

Vadim Petrochenkov (Jan 17 2019 at 15:58, on Zulip):

Then you need to prioritize deeply.

nikomatsakis (Jan 17 2019 at 15:58, on Zulip):

yeah

nikomatsakis (Jan 17 2019 at 15:58, on Zulip):

and maybe we should...

Vadim Petrochenkov (Jan 17 2019 at 15:58, on Zulip):

But our situation doesn't look like that.

nikomatsakis (Jan 17 2019 at 15:58, on Zulip):

"ICE-breakers"

Last update: Nov 20 2019 at 01:30UTC