@WG-prioritization/alerts issue #81357 has been requested for prioritization.
How bad is this? Should we ping the Windows group?
I would nominate the Windows group for bisection/repro yes.
maybe I'm wrong but I have the feeling that bisecting would just get us far back in time; the issues mentioned there can easily have always been sitting there unnoticed because they depends on how Rust tries to wrestle with the windows I/O API (as the commenter points out).
Anyway, this looks like to be an issue that requires immediate attention. It's already nominated so I would simply assign a
P-critical and hopefully tomorrow someone with some specific windows knowledge can chime in and suggest a way forward
Assigned p-critical but anyone feel free to chime in to reframe this issue
Issue #81357's prioritization request has been removed.
(apiraino mistakenly removed I-nominated instead of I-prioritize. Fixed.)
@Camelid actually I think I had removed the
I-nominated on purpose because this issue was discussed last week (and also briefly yesterday).
My reasoning was: what else should be discussed about it, now it also has an assignee.
Why I thought this is referenced here: https://forge.rust-lang.org/compiler/prioritization/procedure.html#summarize-i-nominated-issues
Makes sense? :-)
otoh the lingering
I-prioritize wasnt supposed to be there anymore, so you were right in removing it (thanks)
If you meant to remove the
I-nominated label, feel free to remove it again :)
I removed it because I thought you mistakenly removed it instead of
I-prioritize. It seems you meant to remove both.
It seems you meant to remove both.
yes :) sorry for confusion
Since tomorrow it's release day, having this issue as
P-critical is not helping. During a past meeting we decided that
P-critical issues that are /not/ critical for a release to be downgraded to
P-high (so this was my understanding), and that's what I'll do.
Hopefully this issue will get some attention soon before we enter in the next beta.
Should we bump this back to
I'm ok to push it up back to its original status with the implied meaning that
P-critical == release blocker, so I assume the intent is to work out a solution before the next stable, am I correct?
I personally am not sure it deserves
P-critical but to be honest there's so many
P-high issues that it's hard to know where to prioritize an issue that's like this: "we should be looking into this constantly and trying to solve it asap but it won't block a release"
we should be looking into this constantly and trying to solve it asap but it won't block a release
right and that's my understanding of a
P-high, i.e. also including "P-critical that are not release blockers".
So raising the priority would be just to flag it as "release blocker".
i'd say don't look at how many issue are being labelled p-high or so. Since priority doesn't depend on them