Avoid tagging as I-nominated on toolstate breakage

[spastorino]

r? @Mark-Simulacrum

[Mark-Simulacrum]

We've confirmed with compiler team that we want this, right? If so, r=me -- seems correct but could break - we'll have to see.

[spastorino]

We agreed during last week compiler team meeting. @nikomatsakishave said that as long as we have a mechanism to raise alarm if problems are persisting he would be ok.

With that in mind I've added a step to check toolstate during prioritization on t-compiler, then talked to @Centril who has said that T-release can take care of this.

Please everyone confirm that this is what we want.

[Mark-Simulacrum]

then talked to @Centril who has said that T-release can take care of this

I think this should be a compiler team check -- release team would end up just pinging compiler team creating needless run arounds.

However, we can work out that exact process later, I think, and if we run into trouble in some sense.

@bors r+

[bors]

📌 Commit 5884c9d has been approved by Mark-Simulacrum

[spastorino]

then talked to @Centril who has said that T-release can take care of this

I think this should be a compiler team check -- release team would end up just pinging compiler team creating needless run arounds.

However, we can work out that exact process later, I think, and if we run into trouble in some sense.

@bors r+

Going to add that back to prioritization wg procedure.

[bors]

💡 This pull request was already approved, no need to approve it again.

• There's another pull request that is currently being tested, blocking this pull request: Overhaul of the AllocRef trait to match allocator-wg's latest consens; Take 2 #70362

[bors]

📌 Commit 5884c9d has been approved by spastorino

[spastorino]

doh!, didn't check what I was replying to. Marking as approved by @Mark-Simulacrum again.

@bors r=Mark-Simulacrum

[bors]

💡 This pull request was already approved, no need to approve it again.

• There's another pull request that is currently being tested, blocking this pull request: Overhaul of the AllocRef trait to match allocator-wg's latest consens; Take 2 #70362

[bors]

📌 Commit 5884c9d has been approved by Mark-Simulacrum

[Centril]

I think this should be a compiler team check -- release team would end up just pinging compiler team creating needless run arounds.

@Mark-Simulacrum I don't think that's would be necessary. At this point I think that between the release team members / associated people, we have sufficient experience wrt. infra (Pietro + Mark), compiler internals (Mark + Centril + Jonas + Cuviper + Tmandry), and tools (huuyumi) to contact the tools people directly and work things out in crisis situations (which is very rare).

[Mark-Simulacrum]

Just because we have overlap in the set of folks does not mean that release team should be responsible for identifying whether tool breakage is a problem. It is (obviously) true that we have experience on the release team, but I don't want to see us taking on this responsibility at this time, and I believe it is better suited to the compiler team triage process (which has a pre-triage element for a small group of people). If the release team is to take this responsibility on, it basically means that someone (me? who?) on the release team now needs to start checking in with toolstate regularly. Maybe that's a good thing to discuss doing -- or even setting up alerts -- but I don't want to do that right now as part of this decision to remove the I-nominated tag.

[Centril]

Maybe that's a good thing to discuss doing -- or even setting up alerts -- but I don't want to do that right now as part of this decision to remove the I-nominated tag.

Fair; I'm happy to have this discussion with you / others at some other point though. :)