> On Nov 3, 2020, at 11:34, Alex Blasche <alexander.blas...@qt.io> wrote: > > > >> -----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
I think that this split is very hard to see, realize and understand at the minimum for non-Qt-developers / customers / users, and sometimes even for developers. It is something that we interpret into a combination of two separated fields in JIRA, with the meaning of Fix Version even having dual meaning depending on the “Resolution” state of a task, it requires a custom filter to see which tasks actually were important enough to warrant some of the resources for a fix in the next version. Also it introduces a split within the P1 tasks: Some of them are were deemed more severe than others, so we committed to allocating resources to them (by setting a fix version), and some were considered less important. It is simply easier to see, if this is reflected in the priority. Will my issue be fixed? P0: Yes, as soon as possible. P1: Yes, it was deemed important enough to be allocated resources so it should be fixed in the next release. P2-P5: No idea. In the P2-P5 range differences in priority, timing/fix version whatever, can still be used to differentiate. Br, Eike > > 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
