Stream: t-compiler/wg-prioritization/alerts

Topic: #81357 File implementation on Windows has unsound methods

triagebot (Jan 24 2021 at 21:45, on Zulip):

@WG-prioritization/alerts issue #81357 has been requested for prioritization.


Camelid (Jan 24 2021 at 23:09, on Zulip):

How bad is this? Should we ping the Windows group?

Hameer Abbasi (Jan 25 2021 at 15:06, on Zulip):

I would nominate the Windows group for bisection/repro yes.

apiraino (Jan 27 2021 at 10:34, on Zulip):

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).

apiraino (Jan 27 2021 at 10:35, on Zulip):

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

apiraino (Jan 28 2021 at 11:40, on Zulip):

Assigned p-critical but anyone feel free to chime in to reframe this issue

triagebot (Feb 05 2021 at 00:36, on Zulip):

Issue #81357's prioritization request has been removed.

Camelid (Feb 05 2021 at 00:37, on Zulip):

(apiraino mistakenly removed I-nominated instead of I-prioritize. Fixed.)

apiraino (Feb 05 2021 at 10:30, on Zulip):

@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:
Makes sense? :-)

apiraino (Feb 05 2021 at 10:30, on Zulip):

otoh the lingering I-prioritize wasnt supposed to be there anymore, so you were right in removing it (thanks)

Camelid (Feb 05 2021 at 21:40, on Zulip):

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.

apiraino (Feb 06 2021 at 18:43, on Zulip):

It seems you meant to remove both.

yes :) sorry for confusion

apiraino (Feb 10 2021 at 18:12, on Zulip):

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.

rylev (Feb 12 2021 at 09:31, on Zulip):

Should we bump this back to P-critical?

apiraino (Feb 12 2021 at 09:59, on Zulip):

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?

apiraino (Feb 12 2021 at 09:59, on Zulip):

While I am here, linking the meeting discussion of yesterday about #81357

rylev (Feb 12 2021 at 10:13, on Zulip):

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"

apiraino (Feb 12 2021 at 10:21, on Zulip):

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".
(again, imho)

DPC (Feb 13 2021 at 01:34, on Zulip):

i'd say don't look at how many issue are being labelled p-high or so. Since priority doesn't depend on them

Last update: Apr 15 2021 at 02:15UTC