> -----Original Message----- > From: Development <development-boun...@qt-project.org> On Behalf Of > Jason McDonald
> Looking at the huge list of P1s we have right now, I have absolutely no idea > what issues are genuinely blocking Qt 6.0 or if there are any that I could > help out > with. I could spend literally weeks just reading through all the P1s to try > to figure > out what's really important. I would not like to be in the shoes of whomever > has > to make a go/no-go decision for Qt 6 in the near future. I don't believe reserving P1 for release blockers (as suggested by Eike) solves this problem. A release blocker for timed releases (which is what Qt's been doing for years) is not just a prio field but also a timing issue. After all the trinity of quality - time - resources must be adhered to. Resourcing is generally fixed for a release, the prio field reflects quality and "fix Version" field maps to time. Therefore we have to make tough calls to leave some P1 bugs out as time runs out. Therefore the blocker list for a release is a combo of Fix version and prio Here is Jani's link for them: https://bugreports.qt.io/issues/?filter=22682 The priority field is a standard field. There is no way to remove it. One can hide it somewhat but it is known to show up in different places. Mind you, our triaging process is based on unset prio fields. We check for data to assess the prio and ask for more until we can set the prio. It still doesn't imply that we can verify the bug on our side. One could do that too but this will expand the scope of triaging significantly and I am not sure whether we want to go this far. -- Alex _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
